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ABSTRACT 


This  thesis  analyzes  the  Government  Open  Systems 
Interconnection  Profile  (GOSIP)  and  the  requirements  of  the 
Federal  Information  Processing  Standard  (FIPS)  Publication 
146-1.  It  begins  by  examining  the  International  Organization 
for  Standardization  (ISO)  Open  Systems  Interconnection  (OSI) 
architecture  and  protocol  suites  and  the  distinctions  between 
GOSIP  version  1  and  2.  Additionally,  it  explores  some  of  the 
GOSIP  protocol  details  and  discusses  the  process  by  which 
standards  organizations  have  developed  their  recommendations. 
Implementation  considerations  from  both  government  and  vendor 
perspectives  illustrate  the  barriers  and  requirements  faced  by 
information  systems  managers,  as  well  as  basic  transition 
strategies.  The  result  of  this  thesis  is  to  show  a  transition 
strategy  through  an  extended  and  coordinated  period  of 
coexistence  due  to  extensive  legacy  systems  and  GOSIP  product 
unavailability.  Recommendations  for  GOSIP  protocol  standards 
to  include  capabilities  outside  the  OSI  model  are  also 
presented. 
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I .  IMTRODUCTIOH 

The  US  Government  Open  Systems  Interconnection  Profile  (US 
GOSIP)  is  the  specification  of  the  approach  which  the  US 
Federal  Government  has  adopted  to  interconnect  its  information 
systems  and  enable  them  to  exchange  information  easily  and 
reliably.  The  Open  Systems  Interconnection  (OSI)  suite  is  a 
set  of  internationally  standardized,  vendor  independent 
protocols  defined  by  the  Stable  Implementation  Agreements  for 
Open  Systems  Interconnection  Protocols  from  the  International 
Organization  for  Standardization  (ISO),  the  Consultative 
Committee  for  International  Telegraphy  and  Telephony  (CCITT) 
and  the  Institute  of  Electrical  and  Electronics  Engineers, 
Inc.  (IEEE)  [GOSIP  Institute,  1992].  These  "Workshop 
Agreements"  provide  implementation  specifications  for 
protocols  cited  by  GOSIP,  and  ensure  international  compliance 
for  open  system  interoperability  [FIPS  SP500-177,  1985]. 

Knowledge  and  understanding  of  the  GOSIP  requirements 
becaune  a  critical  issue  for  information  systems  (IS)  managers 
in  August,  1990  when  GOSIP  version  1  became  mandatory  for 
Federal  systems  procurement . 

GOSIP  shall  be  used  by  Federal  Government  agencies  when 
acquiring  computer  network  products  and  services  and 
communications  systems  or  services  that  provide  equivalent 
functionality  to  the  protocols  defined  in  the  GOSIP 
documents.  Currently,  GOSIP  supports  the  Message  Handling 
System  (MHS)  and  File  Transfer,  Access  and  Management 
(FTAM)  applications.  GOSIP  also  supports  interconnection 
of  the  following  network  technologies:  CCITT 
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Reconanendation  X.25;  Carrier  Sense  Multiple  Access  with 

Collision  Detection  (IEEE  802.3);  Token  Bus  (IEEE  802.4); 

and  Token  Ring  (IEEE  802.5).  [FIPS  146,  1988] 

GOSIP  version  2  expanded  the  requirements  to  include  protocols 
for  Virtual  Terminal  (VT),  End  System  to  Intermediate  System 
Routing  (ES-IS),  and  Integrated  Services  Digital  Networks 
(ISDN)  and  became  mandatory  for  Federal  procurement  on  3 
October,  1992  [FIPS  146-1,  1991]. 

The  motivation  behind  adopting  an  open  system  standard  was 
to  save  money  by  providing  increased  communications 
capabilities  through  effective  and  interoperable  computer 
networks,  to  reduce  development  costs  and  expand  the 
competitive  marketplace.  The  stated  objectives  for  this 
protocol  standard  are  [Federal  Register,  1991]: 

•  To  achieve  interconnection  end  interoperability  of 
computers  and  systems  that  are  acquired  from  different 
manufacturers  in  an  open  systems  environment. 

•  To  reduce  the  costs  of  computer  network  systems  by 
increasing  alternative  sources  o:^  supply. 

•  To  facilitate  the  use  of  advanced  technology  by  the 
Federal  Government. 

•  To  stimulate  the  development  of  commercial  products 
compatible  with  Open  Systems  Interconnection  (OSI) 
standards. 

The  assumption  was  that  by  selecting  a  core  subset  of  OSI 
and  requiring  that  it  be  provided  for  all  Government 
information  systems,  GOSIP  would  create  a  huge  standardization 
market  for  OSI  applications  and  network  solutions,  thereby 
bringing  down  the  prices  of  OSI  hardware  and  software  [GOSIP 
Institute,  1992]. 
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A.  PURPOSE 


While  the  requirements  of  GOSIP  are  quite  specific  and  are 
supported  by  extensive  technical  references,  there  is  little 
or  no  guidance  on  how  to  transition  from  legacy  systems  into 
the  international  open  systems  world  of  OS I.  The  Department 
of  the  Navy  (DoN)  is  committed  to  the  open  systems  concept  and 
directs  that  transition  from  non-GOSIP  systems  will  ue 
accomplished  where  technically  feasible,  operationally 
sufficient,  and  affordable.  [DoN,  1993] 

Unfortunately,  the  ISO  body,  in  developing  open  system 
standards,  has  intentionally  produced  a  displacement 
technology  in  an  environment  of  extended  coexistence.  The 
committees  which  produce  OS I  standards  are  very  careful 
neither  to  reference  nor  accommodate  any  non-OS I  technology 
(i.e.,  the  installed  base).  Management  issues  purposefully 
left  outside  the  scope  of  GOSIP  are: 

•  coexistence  between  OSI  and  the  installed  base;  and, 

•  transition  from  the  installed  base  to  OSI. 

There  are  even  barriers  to  transitioning  from  one  generation 
of  OSI  protocols  to  the  next,  with  application 
interoperability  issues  of  1984  and  1988  software  versions 
unresolved  [Rose,  1992]. 

The  purpose  of  this  rhesis  is  to  emphasize  transition 
options  in  a  period  of  coexistence  between  existing  systems 
and  GOSIP-compliant  systems  with  the  primary  focus  on 
management  issues  of  transition  as  effected  by  regulation,  the 
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standardization  process  and  industry  support.  This  plan 
applies  to  information  systems  requiring  inter-computer 
connection  services. 

B.  OBJECTIVES 

The  60SIP  mandate  is  quite  specific  on  what  it  requires 
and  when,  however  it  is  conspicuously  missing  any 
implementation  or  transition  strategies.  The  objective  of 
this  study  is  to  contribute  to  DoD  conversion  efforts.  An 
analysis  of  industry  support  for  GOSIP  and  current 
implementation  efforts  is  presented  as  a  tool  for  future 
transition  efforts. 

C.  SCOPE 

The  analysis  of  requirements  and  mechanisms  which  direct 
and  enedile  implementation  of  GOSIP  will  be  conducted  as  a 
basis  for  evaluating  transition  strategies  in  order  to  guide 
management  efforts  in  adopting  GOSIP.  The  goal  is  to  provide 
a  transition  strategy  which  is  technically  feasible  and 
resource  responsible  while  maintaining  operational  stability. 

D.  ORGANIZATION  OF  STUDY 

1.  The  Standards  Process 

Chapter  II  describes  the  process  whereby  standards  are 
developed  and  adopted  by  the  ISO  and  how  the  ISO's  process 
differs  from  the  Internet  Engineering  Task  Force's  process. 
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The  course  of  events  that  create  standards  dramatically  affect 
how  the  marketplace  responds  with  product  development. 

2.  Open  Protocol  Suites 

Chapter  III  presents  the  reader  with  a  brief 
background  on  the  make-up  of  network  protocol  stacks  as 
defined  by  ISO  and  NIST.  It  is  designed  to  assist  the  user  in 
understanding  and  interpreting  GOSIP  technical  information. 

3 .  GOSIP  Background 

Chapter  IV  provides  expanded  background  information  on 
GOSIP  functionality  and  provides  amplifying  information  on 
procedures  and  guidelines  for  implementing  GOSIP. 

4.  Product  Development  and  Support 

Chapter  V  examines  computer  industry  support, 
commitment  and  product  development  of  GOSIP  compliant  products 
and  assesses  the  future  of  OSI  interoperability. 

5 .  Transition  Strategies 

Chapter  VI  provides  three  stages  of  transition 
focusing  on  an  extended  period  of  coexistence.  Six  generic 
transition  approaches  along  with  specific  military 
considerations  are  presented. 

6 .  Conclusions 

The  final  chapter  provides  conclusions  and 
recommendations  from  the  study. 


5 


II. 


THE  STAMDAROS  PROCESS 


It  is  currently  mandated  that  new  computer  networks  in  DoD 
will  use  a  foundation  of  OSI  protocols.  Computing 
environments  are  rapidly  migrating  toward  truly  "openness"  and 
total  interoperability.  However#  the  path  of  transition  and 
the  final  destination  is  unclear  and  is  complicated  by 
conflicts  between  standards  organizations  and  vendors.  The 
FIPS  146-1,  directing  that  OSI  protocols  be  implemented,  in 
itself  is  not  an  answer  to  how  to  manage  the  transition.  For 
example,  the  OSI  protocol  Common  Management  Information 
Protocol  (CHIP)  has  at  least  nine  different  profiles  availeOsle 
for  implementation.  [Burns,  1992]  Similar  examples  dominate 
the  OSI  stack  while  Internet  protocols  are  adding  improved  and 
interoperable  features.  Unfortunately,  the  standards  process 
does  not  respond  to  either  users  or  industry  but  seeks  to 
accommodate  every  possible  point  of  view. 

Conflicts  in  the  standardization  of  technology  is  not  a 
new  dilemma  brought  on  by  advancements  in  computer  networks. 
There  have  been  successes  and  failures  in  standardization 
throughout  history.  The  belief  that  a  common  international 
stemdard  is  critical  for  continued  coexistence  is  inconsistent 
with  working  examples  of  standardization.  Television 
broadcasting,  the  metric  system  and  monetary  exchange  are 
working  examples  of  how  standardization  is  not  an  imperative 
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for  international  coexistence,  while  a  strict  adherence  to  a 
standard  in  telephone  switching  and  international  air  traffic 
control  is  critical  and  effective.  The  determining  factors  in 
establishing  and  enforcing  a  technology  standard  are  the 
requirements  of  an  industry  to  achieve  its  goals  and  the 
amount  of  capital  it  is  willing  to  invest.  Users  and  managers 
want  to  effectively  and  efficiently  maximize  the  use  of  tools 
to  maximize  a  competitive  advantage  in  a  cost-effective 
manner.  Technology  producers  desire  to  provide  what  the  users 
want  in  order  to  maximize  profit.  Thus  the  "standard"  is  what 
is  desirable  and  for  sale  at  a  competitive  price.  We  live  in 
a  de  facto  world  where  we  document  successful  innovations  and 
procedures  until  they  becomes  the  common  wisdom  of  the  day 
[Taylor,  1993].  If  standardization  and  acceptance  were 
dependent  on  legislation  or  declaration  then  the  law  requiring 
the  metric  system  in  the  US  should  have  been  sufficient  to 
facilitate  the  transition. 

Critical  to  the  eventual  adoption  of  a  standard  is  the 
process  by  which  it  is  developed.  A  process  that  involves  the 
users  is  more  likeJv  to  reflect  the  de  facto  requirements 
already  in  place. 

A.  INTERNATIONAL  ORGANIZATION  FOR  STANDARDIZATION  (ISO) 

. . .  there  are  about  5 , 000  people  who  are  part 
of  that  committee.  These  guys  have  a  hard 
time  sorting  out  what  day  to  meet,  and  whether 
or  not  to  eat  croissants  or  doughnuts  fcr 
breakfast  let  alone  how  to  define  how  ail 
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these  complex  layers  are  going  to  be  agreed 
upon.  [Rose,  1992] 

The  GOSIP  program  is  a  complex  and  lengthy  process  of 
requirements  analysis,  specification  development,  public 
review,  product  development,  testing,  and  procurement.  The 
seven  steps  from  model  to  deployment,  shown  in  Figure  1,  is 
overburdened  with  controversy  and  compromise  on  an 
international  scale. 


1 .  OSI  Model 

The  International  Organization  for  Standardization 
(ISO)  began  development  of  the  Open  Systems  Interconnection 
model  in  1978.  Four  years  later,  with  the  cooperation  of  the 
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Consultative  Conanittee  for  International  Telegraphy  and 
Telephony  (CCITT)  the  OSI  Basic  Reference  Model  was  published 
(ISO  International  Standard  7498  and  CCITT  X.200). 

2 .  Layer  Standards 

The  lower  five  layers  of  the  model  were  published  less 
than  a  year  later  for  X.25  Wide  Area  Networks  (WAN)  and  IEEE 
802  Local  Area  Networks  (LAN),  as  well  as  for  Transport, 
Session,  and  the  X.400  Message  Handling  System  (MHS).  The 
joint  ISO/CCITT  progreun  expanded  to  include  the  International 
Electrotechnical  Commission  (lEC)  in  a  Joint  Technical 
Committee  (JTC)  to  standardize  overlapping  activities. 

3 .  Functional  Standards 

The  publication  of  ISO/IEC/CCITT  standards  in  the  mid 
1980 's  moved  vendor  product  representatives  and  user 
representatives  to  form  workshops  to  discuss  OSI 
implementation.  Three  Functional  Standards  Regional  Workshops 
discussed  OSI  producability,  interoperability,  and  wide 
acceptability  beginning  in  1987. 

•  National  Institute  of  Standards  and  Technology  (NIST)  OSI 

Implementors  Workshop  (OIW) 

•  European  Workshop  on  Open  Systems  (EWOS) 

•  Asia  and  Oceania  Workshop  (AOW) 

4.  Profiles 

Governmental  bodies  created  profiles  by  referencing 
their  procurement  requirements  to  Regional  Workshop 
Agreements.  Specifications  of  subsets,  options,  and 
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parameters  standardized  requirements  for  vendors  attempting  to 
produce  product  in  large  quantities.  Similar,  but  unique, 
profiles  include  US  GOSIP,  UK  GOSIP,  and  European  Procurement 
Handbook  for  Open  Systems  ( EPHOS ) . 

5 .  Products 

Once  profiles  have  been  written  into  procurement 
specifications,  development  of  working  system  prototypes  and 
contract  competition  begins.  Request  for  proposals  are 
published  with  specific  system  requirements  for  contractor 
bids.  The  award  of  a  contract  will  begin  the  product 
development  phase. 

6 .  Testing 

Conformance  to  profile  testing  centers  have  been 
established  in  the  three  OSI  world  regions.  Independent 
consortiums  established  by  OSI  vendors  and  major  users  such  as 
Corporation  for  Open  Systems  International  (COS)  provide 
testing  facilities  for  FTAM,  X.400,  TP4,  and  CLNP. 
Interoperability  testing  is  also  conducted  by  independent 
laboratories  esteiblished  by  NIST  and  OSINET,  with  results 
submitted  and  verified  by  the  Joint  Interoperability  Test 
Center  (JITC). 

7 .  Deployment 

Installation  and  successful  operation  of  OSI  products 
in  an  "open"  environment  is  the  ultimate  test  of  a  standard. 
The  obvious  problem  with  this  system  lies  not  in  the 
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progression  of  steps,  but  rather  in  the  move  from  profile  to 
product.  Full  system  development  is  often  costly  and  risky, 
and  in  today's  economic  environment  resources  are  not 
available  for  independent  and  speculative  product  R&D.  The 
federal  procurement  process  requires  vendors  to  have  actual 
working  products  before  they  can  enter  the  bidding  process. 
This  dictates  what  products  will  be  developed  in  support  of  a 
profile.  This  phenomenon  is  unique  in  the  government  arena 
because  the  users  of  the  developing  technology  are  often 
unidentified.  Private  industry  instantly  gains  valuable 
feedback  from  end-users  during  prototyping,  alpha  and  beta 
tests  and  either  continues  product  development,  which  is  a 
reflection  of  commercial  user  needs,  or  abandons  them  for  a 
more  cost  effective  solution.  Because  government  is  not 
responsive  to  the  market  place,  interoperability  and  product 
availcibility  becomes  a  limiting  factor. 

B.  INTERNET  STANDARDIZATION  PROCESS 

The  Internet  suite  of  protocols  is  developed  in  a 
dramatically  different  process.  The  development  of  the  DoD 
Open  Systems  Profile  progressed  through  four  stages. 

1 .  Definition 

A  technological  advancement  is  documented  and 
supported  by  a  constituency  of  vendors  and/or  users. 
Prototype  implementations  of  a  new  technology  undergo  review 
and  appraisal.  If  the  document  passes  review  as  a  defining 
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dociunent  of  the  technology,  it  is  reclassified  as  a  proposed 
stemdard . 

2 .  Proposal 

Once  a  proposed  standard  is  accepted  the  proponents 
must  demonstrate  interoperability  and  usefulness.  This 
process  is  given  a  deadline  of  six  to  nine  months,  during 
which  time  there  must  be  significant  experience  with 
implementation.  An  openly-availcd>le,  working  reference 

implementation  must  be  demonstrated  to  provide 
interopercdiility  evidence.  If  public  scrutiny  of  the 
technology  shows  that  the  criteria  has  been  met  then  the 
document  becomes  a  draft  standard. 

3 .  Draft 

A  draft  standard  has  an  additional  six  to  nine  months 
to  demonstrate  its  interoperability  in  several  independent 
installations.  If  extensive  deployment  of  the  document  is 
successful  it  becomes  a  full  standard. 

4 .  Full  Standard 

The  document  is  amended  and  modified  as 
incompatibility  or  weaknesses  are  identified.  The  important 
issue  in  the  adoption  process,  is  that  at  every  level  there 
are  products  in  place  and  in  operation  for  technical  review. 
Implementation,  deployment  and  interoperability  are  developed 
simultaneously,  providing  understanding  and  availability  for 
users  and  vendors. 
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III. 


OPEN  PROTOCOL  SUITES 


A.  OPEN  SYSTEMS  IMTERCONMECTIOH  (OSI)  REFERENCE  MODEL 

The  Consultive  Committee  on  International  Telephone  and 
Telegraph  (CCITT)  developed  a  reference  model  which  groups 
common  protocol  functions  into  seven  layers,  as  shown  in 
Figure  2.  These  seven  layers  represent  groupings  of  major 
functions  required  to  effectively  send  data  through  a  network. 
The  OSI  Reference  Model  layers  are  grouped  according  to  these 
major  functions:  application,  presentation,  session, 

transport,  network,  data  link,  and  physical.  Additionally, 
Figure  2  groups  the  functions  into  categorized  services: 
Application  Services,  Networking  Services,  and  Transmission 
Services. 

The  Open  System  Interconnection  (OSI)  profile  is  a  concept 
in  data  communications  whereby  computer  systems  are  able  to 
communicate  in  an  open  environment  without  knowledge  of 
specific  characteristics  of  remote  host  computers  [Boland, 
1991].  The  network  structure,  established  by  the  ISO,  is  a 
series  of  components  or  layers  that  work  together  to  provide 
a  service.  Each  of  the  seven  layers  performs  a  related  subset 
of  the  functions  required  to  communicate  with  another  system. 
It  relies  on  the  next  lower  layer  to  perform  more  primitive 
functions  and  to  conceal  the  details  of  those  functions 
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Application  Services 


Responsible  for  information  transfer  between  two  network 
applications.  This  involves  such  functions  as  security  checks, 
identification  of  the  two  participants,  availability  checks, 
negotiating  exchange  mechanisms,  and  most  importantly, 
initiating  the  exchanges  themselves. 


Responsible  for  the  proper  formatting  of  information.  This 
involves  negotiating  formats,  transforming  information  into  th« 
agreed  upon  format  and  generating  session  re<iuests  for  service 


Responsible  for  the  management  of  connections  between 
cooperating  applications.  This  involves  establishing  and 
releasing  sessions,  synchronizing  information  transfer  over 
these  sessions  and  mapping  session- to -transport  and 
session- to -application  connections . 


Networking  Services 


Responsible  for  managing  connections  between  two  end  nodes 
involved  in  an  information  exchange.  Primary  functions  includ* 
estaiblishing  and  releasing  end-to-end  connections,  controlling 
the  size,  sequence  and  flow  of  transport  packet  and  mapping 
transport  and  network  addresses. 


Responsible  for  routing  information  among  sources,  intermediate 
euid  destination  nodes.  Primary  routing  is  provided  through 
network  address  processing,  connection-oriented  and 
connectionless  exchange  management,  segwientation  and  blocking 
of  network  packets. 


Responsible  for  the  reliable  treinsfer  of  data  frames  over  the 
physical  layer.  Relieibility  is  provided  through  proper 
sequencing,  error  detection,  recovery  and  flow  control. 


Transmission  Services 


Responsible  for  the  mechanical,  electrical,  functional  and 
procedural  aspects  of  data  circuits  among  network  nodes.  Of 
primary  importance  are  link  activation  and  deactivation,  fault 
and  performance  management  of  circuits  emd  sequencing  of  bit 
streams. 


Figure  2  OSI  Reference  Model 


[Stallings,  1991]. 

1.  The  Application  Layer  (Layer  7) 

The  Application  Layer  (Layer  7)  provides  services  to 
application  processes  that  lie  outside  the  reference  model. 
Layer  7  allows  for  protocols  and  services  required  by 
particular  user-designed  applications.  Functions  satisfying 
these  particular  user  requirements  are  contained  in  this 
layer.  Representation  and  transfer  of  information  necessary 
to  communicate  between  applications  are  the  responsibility  of 
the  lower  levels. 

2.  The  Presentation  Layer  (Layer  6) 

The  Presentation  Layer  (Layer  6)  provides  for  the 
negotiation  and  establishment  of  the  transfer  syntax,  which 
represents  the  encoding  of  values  for  the  purpose  of 
transferring  structured  data  types.  Layer  6  negotiates  the 
way  information  is  represented  for  exchange  between  entities. 
The  presentation  layer  provides  representation  of:  1)  data 
transferred  between  application  entities,  2)  the  data 
structure  that  the  application  entities  use,  and  3)  operations 
on  the  data's  structure.  The  presentation  layer  is  concerned 
only  with  the  syntax  of  the  transferred  data,  with  the  data's 
meaning  known  only  to  the  application  entities. 

3.  The  Session  Layer  (Layer  5) 

The  Session  layer  (Layer  5)  is  the  user's  interface  to 
the  network.  This  layer  manages  the  connection  between  users. 
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Layer  5  allows  cooperating  application  entities  to  organize 
and  synchronize  conversation  and  to  manage  data  exchange.  To 
transfer  the  data,  session  connections  use  transport 
connections.  During  a  session,  session  services  are  used  by 
application  entities  to  regulate  dialogue  by  ensuring  an 
orderly  message  exchange  on  the  session  connection. 

4.  The  Transport  Layer  (Layer  4) 

The  Transport  Layer  (Layer  4)  provides  a  network- 
independent  transport  service  to  the  session  layer.  The  basic 
function  of  the  transport  layer  is  to  accept  data  from  the 
session  layer,  and  ensure  that  the  pieces  all  arrive  correctly 
at  the  other  end.  Layer  4  connection-oriented  service 
provides  reliable,  transparent  transfer  of  data  between 
cooperating  session  entities.  The  transport  layer  entities 
optimize  the  available  network  services  to  provide  the 
performance  required  by  each  session  entity.  Optimization  is 
constrained  by  the  overall  demands  of  concurrent  session 
entities  and  by  the  quality  and  capacity  of  the  network 
services  available  to  transport  layer  entities.  Transport 
protocols  regulate  flow,  detect  and  correct  errors,  and 
multiplex  data  an  end-to-end  basis. 

5.  The  Network  Layer  (Layer  3) 

The  Network  Layer  (Layer  3)  routes  information  from 
one  network  computer  to  another.  Layer  3  provides  message 
routing  and  relaying  between  end  systems  on  the  same  network 
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or  on  interconnected  networks,  independent  of  the  transport 
protocol  used.  The  network  layer  may  also  provide  hop-by-hop 
network  service  enhancements,  flow  control,  and  load  leveling. 
Services  provided  by  the  network  level  are  independent  of  the 
distance  separating  interconnected  networks. 

6.  The  Data  Link  Layer  (Layer  2) 

The  Data  Link  Layer  (Layer  2)  provides  a  reliable 
means  of  transmitting  data  across  a  physical  link.  Layer  2 
provides  communication  between  two  or  more  adjacent  systems. 
The  data  link  layer  performs  frame  formatting,  error  checking, 
addressing,  and  other  functions  necessary  to  ensure  accurate 
data  transmission  between  adjacent  systems.  The  data  link 
layer  can  operate  in  conjunction  with  several  different  access 
methods  in  the  physical  layer. 

7.  The  Physical  Layer  (Layer  1) 

The  Physical  Layer  (Layer  1)  provides  a  physical 
connection  for  the  transmission  of  data  among  network  systems 
and  a  means  by  which  to  activate  and  deactivate  a  physical 
connection.  Layer  1  provides  physical  connection  for 
transmission  of  data  between  link  entities.  Physical  layer 
entities  perform  electrical  encoding  and  decoding  of  the  data 
for  transmission  over  a  medium  and  regulate  access  to  the 
physical  network. 
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B.  OOSIP  VERSION  1 


GOSIP  is  the  result  of  a  desire  to  simplify  and  ease  the 
process  of  assimilating  OSI  technology  into  Federal  agencies 
by  specifying  a  common  generic  set  of  reguirements.  GOSIP 
versions  1  and  2  are  technical  specifications  which  contain  a 
core  set  of  protocols  and  services.  Version  2  contains 
additional  functions  while  retaining  all  the  functionality  of 
version  1.  The  GOSIP  protocols  are  described  in  the  Federal 
Information  Processing  Standards  (FIPS)  Publication  146-x, 
with  FIPS  146-1  of  3  April,  1991  the  current  standard.  Figure 
3  shows  the  GOSIP  version  1  architecture  within  the  OSI  stack. 

Because  GOSIP  specifies  a  subset  of  the  OSI  protocols  many 
of  the  functions  are  defined  by  referencing  the  "Workshop 
Agreements"  which  give  specific  technical  information  for 
protocol  conformance.  These  details  are  found  in  the  National 
Institute  of  Standards  ond  Technology  (NIST)  Federal 
Information  Processing  Standards  (FIPS)  Special  Publication 
500-177. 

1.  Application  Layer 

•  Message  Handling  System  (MHS) 

Message  transfer  services  and  interpersonal  message 
services  are  as  specified  by  section  7  of  the  Workshop 
Agreements.  Communication  between  two  Message  Transfer  Agents 
takes  place  as  specified  by  CCITT  Recommendation  X.410  (1984). 
Transport  class  0  and  the  Connection  Oriented  Service  (CONS) 
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will  be  used  by  end-systems  when  messaging  over  public 
messaging  domains  on  public  data  networks.  End-systems  on 
private  domains  must  use  transport  class  4.  Private 
management  domain  end-systems  connected  to  public  domains 
conforming  to  X.410  must  implement  transport  class  0  when 
relaying  between  domains. 

•  File  Transfer,  Access  and  Management  (FTAM) 

FTAM  services  are  as  specified  by  section  9  of 
Workshop  Agreements.  Limited-purpose  or  full-purpose  file 
transfer  services,  as  specified  by  ISO  8571-4,  operate  as  the 
initiator  of  remote  file  activity,  and  as  a  responder  to 
requests  for  remote  file  activity,  or  as  both  initiator  and 
responder. 

•  Association  Control  Service  Element  (ACSE) 

The  ACSE  is  as  specified  by  section  5.5  and  5.12  of 
the  Workshop  Agreements.  A  fixed  value  for  the  Application 
Entity  (AE)  Title,  specified  by  ISO  8650,  support  FTAM 
requirements  for  exchange  of  AE  types  and  logical 
configuration  of  AE  types  for  non-GOSIP  systems. 

2 .  Presentation  Layer 

•  Connection-oriented  Presentation  Protocol 

Presentation  protocols  are  as  specified  by  section  5.8 

and  5.12  of  the  Workshop  Agreements  and  by  ISO  8823. 
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3 .  Session  Layer 

•  Connection-oriented  Session  Protocol 

Session  protocols  are  as  specified  by  section  5.9  and 
5.12  of  Workshop  Agreements  and  by  ISO  8327. 

4 .  Transport  Layer 

•  Connection-oriented  Transport  Protocol  Class  4 
Connection-oriented  Transport  Protocol  (COTS) 

transport  class  4  are  as  specified  by  section  4.5.1  of  the 
Workshop  Agreements  and  are  amended  by  ISO  8073  to  support 
CCITT  X.400  (1984). 

5 .  Network  Layer 

•  Connectionless  Mode  Service  (CLNS) 

Connectionless  network  service  is  required  for 

Government-wide  interoperability  and  connects  logically 
distinct  local  and  long-haul  subnetworks.  CLNS  is  provided  by 
ISO  Connectionless  Network  Protocol  and  is  required  to  support 
1984  CCITT  X.25,  HDLC  LAP  B  (ISO  7776),  ISO  8802.2  and  Draft 
International  Standard  9574  (ISDN). 

•  Connectionless  Network  Protocol  (CLNP) 

CLNPs  are  implemented  as  specified  by  section  3.5  of 
the  Workshop  Agreements  and  by  ISO  8473.  CLNP  must  be 
implemented  and  used  for  internetworking  or  concentrated 
subnetworks,  and  End  System  to  Intermediate  System  (ES-IS) 
protocol  connects  end-systems  to  local  area  or  point-to-point 
subnetworks . 
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6.  Data  Link  Layer 

•  X.25  Packet  Layer  Protocol  (ISO  8208) 

•  HDLC  LAP  B  (ISO  7776) 

•  Logical  Link  Control  (ISO  8802-2) 

7 .  Physical  Layer 

•  V. 35  (CCITT) 

•  RS-232-C  (EIA) 

•  CSMA/CD  (ISO  8802-3) 

•  Token  Bus  (ISO  8802-4 ) 

•  Token  Ring  (ISO  8802-5) 

C.  GOSIP  VERSION  2 

GOSIP  version  2  includes  all  protocols  from  version  1  with 
the  following  additions  defined  by  FIPS  Pub  146-1.  Figure  4 
shows  GOSIP  version  2  within  the  OSI  stack. 

1 .  Application  Layer 

•  Office  Document  Architecture  (ODA) 

The  ODA  Standard  specifies  rules  for  describing  the 
logical  and  layout  structures  of  docvunents  as  well  as  rules 
for  specifying  character,  raster,  and  geometric  content  of 
dociunents,  thus,  providing  for  the  interchange  of  complex 
documents.  Interchanged  dociunents  may  be  in  formatted  form 
(i.e.,  for  presentation  such  as  printing,  displaying),  in 
processcd^le  form  (i.e.,  for  further  processing  such  as 
editing)  or  in  formatted  processable  form  (i.e.,  for  both 
presentation  and  further  processing).  Transfer  services,  for 
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ODA  documents,  may  be  provided  by  either  MHS  or  FTAM.  If  the 
MHS  application  is  used,  OdaBodyParts  are  encoded  for 
transmission  over  a  CCITT  X.400  (1984)  service.  When  using 
FTAM  to  transfer  an  ODA  file,  the  FTAM-3  document  type  should 
be  specified;  however,  since  files  that  are  not  ODA  files  can 
have  the  same  document  type,  it  is  left  up  to  the  user  of 
application  programs  that  remotely  access  files  using  FTAM  to 
know  that  a  given  file  contains  ODA  information. 

•  Virtual  Terminal  (VT) 

VT  Systems  are  specified  to  support  both  1)  simple 
systems,  and  2)  forms  capaible  systems,  by  section  14  of  the 
Workshop  Agreements. 

A  simple  system  provides  the  functions  of  a  teletype 
(TTY)  compatible  device  that  supports  a  dialogue  of  a  simple 
line  or  character  at  a  time.  Such  a  system  uses  control 
character  (single)  functions  from  the  ASCII  character  set, 
such  as  "carriage  return",  "form  feed",  "horizontal  tab",  and 
"back  space".  A  simple  system  supports  the  TELNET  profile 
specified  in  section  14.8.1  of  the  Workshop  Agreements.  The 
TELNET  profile  requires  Asynchronous  mode  (A-mode)  of 
operation  (i.e.,  no  token  handling  protocols  are  needed)  and 
specifies  simple  delivery  control. 

A  forms  capable  system  is  intended  to  support  forms- 
based  applications  with  local  entry  and  validation  of  data  by 
the  terminal  system.  A  forms  capable  system  supports 
functions  such  as  "cursor  movement",  "erase  screen",  and 
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••field  protection".  A  fornis-cap2dDle  system  supports  the  forms 
profile  specified  in  section  14.8.3  of  the  Workshop 
Agreements.  The  forms  profile  requires  the  Synchronous  mode 
(S-mode)  of  operation  and  specifies  simple  delivery  controls. 

The  Basic  Class  VT  International  Standard  specifies 
three  negotiation  option  protocols:  No  Negotiation,  Switch 
Profile,  and  Multiple  Interaction  Negotiation  which  are  all 
independent  of  VT  profiles.  Multiple  Interaction  Negotiation 
is  not  addressed  by  the  Workshop  Agreements,  but  any  system 
claiming  support  of  this  negotiation  option  must  also  support 
the  Switch  Profile  Negotiation  and  the  No  Negotiation  options. 
Any  system  supporting  Switch  Negotiation  Profile  must  also 
support  the  No  Negotiation  option.  Seven  bit  USASCII,  as  well 
as  the  International  Reference  Version  (IRV)  of  ISO-646 
graphic  repertoires,  must  be  supported  by  both  simple  and 
forms  capable  systems. 

2 .  Presentation  Layer 

There  are  no  additions  to  the  presentation  layer 
protocols  in  GOSIP  version  2.  It  remains  defined  by  FIPS  Pub 
146  (GOSIP  version  1). 

3 .  Session  Layer 

There  are  no  additions  to  the  session  layer  protocols 
in  GOSIP  version  2.  It  remains  defined  by  FIPS  Pub  146  (GOSIP 
version  1 ) . 
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4 .  Transport  Layer 

•  Connectionless  Mode  Transport  Service  (CLTS) 

Optional  connectionless  mode  transport  service  for 

GOSIP  end-systems  may  be  specified  only  as  an  addition  to  the 
required  connection-oriented  transport  seirvice.  Although  no 
GOSIP  mandated  protocols  require  CLTS,  a  number  of  non-GOSIP 
protocols  widely  available  in  industry  can  use  CLTS  as  an 
efficient  means  of  communicating  across  local  area  networks. 
The  CLTS  option  shall  be  implemented  using  ISO  8602  according 
to  section  4.6  of  the  Workshop  Agreements. 

5 .  Network  Layer 

•  End  System  to  Intermediate  System  (ES-IS)  Routing 
For  end-systems  connected  to  local  area  and  Point  to 

Point  subnetworks,  the  end  system  to  intermediate  system  (CLNP 
ES-IS)  routing  service  shall  be  provided  by  the  ES-IS  protocol 
ISO-9542  implemented  as  specified  in  the  Workshop  Agreements 
section  3.8.1.  For  end-systems  connected  to  wide  area 
networks,  provision  for  an  end  system  to  intermediate  system 
routing  service  is  network  specific. 

•  Connection-oriented  Network  Service  (CONS) 

The  CONS  is  an  additional,  optional  service  that  may 
be  specified  for  end-systems  that  is  directly  connected  to 
X.25  wide  area  networks  and  ISDNs.  Use  of  this  service  can, 
under  certain  circumstances,  avoid  the  overhead  associated 
with  CLNP  and  may  permit  interoperation  with  end-systems  that 
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do  not  comply  with  GOSIP  (i.e.,  do  not  implement  CLNP).  CONS 
shall  be  provided  by  the  X.25  Packet  Level  Protocol  (PLP). 
The  mapping  of  the  elements  of  the  CONS  to  the  elements  of  the 
X.25  PLP  is  according  to  ISO-8878  and  as  specified  in  section 
3.6.1  ( except  section  3 . 6 . 1 . 3 )  of  the  Workshop  Agreements . 

•  Integrated  Services  Digital  Network 

Integrated  Services  Digital  Network  (ISDN)  enables 
X.25  PLP  data  to  be  sent  across  the  D  channel,  sharing  the 
channel  with  signaling  data,  and  across  a  B  channel.  When 
operation  of  X.25  over  a  B  channel  is  selected,  the  B  channel 
can  be  provided  as  a  switched  service  or  a  permanent  service. 
ISDN  physical  and  data  link  layer  access  as  specified  by 
section  2.7.2  of  the  Workshop  Agreements. 

6.  Data  Link  Layer 

There  are  no  additions  to  the  data  link  layer 
protocols  in  GOSIP  version  2.  It  remains  defined  by  FIPS  Pub 
146  (GOSIP  version  1). 

7 .  Physical  Layer 

•  RS-530  (El A) 

GOSIP  version  2  requires  one  additional  physical 
interface  protocol. 
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IV. 


GOSIP  BACKGROUIID 


This  chapter  provides  expanded  background  information  on 
GOSIP  and  provides  amplifying  information  for  procedures  and 
guidelines  in  implementing  GOSIP.  Additional  GOSIP 

implementation  specifics  are  found  in  Appendix  A. 

A.  GOSIP  APPLICABILITY 

Since  August,  1990,  the  procurement  of  new  computer 
networks  and  major  upgrades  to  existing  systems  have  required 
GOS IP-conformant  products.  Because  GOSIP  deals  with 
communications  functionality  it  does  not  specify  specific 
hardware,  software  or  operating  systems.  This  means  that 
GOSIP  requirements  may  apply  to  all  types  of  systems,  in  all 
types  of  environments  regardless  of  size  or  communication 
medium  used  [Boland,  1991].  There  are  three  general  criteria 
for  GOSIP  applicability: 

•  there  must  be  computer-to-computer  communications; 

•  using  an  autonomous  communication  system; 

•  and  communications  functionality  must  be  contained  in 
GOSIP. 

GOSIP  applies  to  communications  between  computer  systems 
providing  standard  applications  over  a  network  and  reliable 
end-to-end  transfer  services.  Thus,  GOSIP  is  designed  to 
provide  a  set  of  flexible  functions  to  be  used  on  any  system 
with  the  ediility  to  interconnect  to  create  a  larger  network. 
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B.  OPEN  SYSTEMS  EMVIRONMEIIT  (OSE) 


Figure  5  shows  a  generally  accepted  representation  of  the 
OSE  Reference  Model.  This  model  consists  of  three  major 
components  (Application  Software,  Application  Platforms  and 
Platform  External  Environment)  with  intervening  interfaces 
(Application  Program  Interface  (API)  and  External  Environment 
Interface  (EEI)). 


Application 

Software 

Application 

Application 

Platform 

Interface 

External 

Platform 

External 

Environment 

Interface 

Figure  5  OSE  Reference  Model 


1.  Application  Software 

The  application  software  is  the  computing  element 
supporting  particular  operational  needs  (word  processing, 
databases,  spreadsheets,  graphical  drawing)  and  includes  data, 
documentation  and  training,  as  well  as  programs. 
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2.  Application  Platform 

The  application  platform  is  composed  of  the  collection 
of  hardware  and  software  components  that  provide  the  services 
used  by  application  programs.  Application  platforms 
facilitate  portable  application  programs  through  services 
accessed  by  Application  Program  Interfaces  (APIs)  that  make 
the  specific  characteristics  of  the  platform  transparent  to 
the  application  (i.e.,  printer  and  I/O  interrupts). 

3.  Platform  External  Environment 

The  platform  external  environment  consists  of  those 
system  elements  which  are  external  to  the  application  program 
and  the  application  platform  (i.e.,  remote  gateways,  LANs  and 
WANs) . 

4.  Application  Program  Interface  (API) 

The  API  is  the  interface,  or  set  of  functions  between 
the  application  software  and  the  application  platform.  APIs 
support  software  portability  by  providing  a  common  interface 
as  an  intermediary  function.  An  API  is  categorized  according 
to  the  services  accessible  through  it;  User  interface, 
information  interchange,  communications  or  internal  systems. 

5.  External  Environment  Interface  (EEI) 

The  EEI  is  the  interface  which  supports  information 
transfer  between  the  application  platform  and  the  external 
environment.  An  EEI  is  categorized  to  the  type  of  information 
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transfer  services  provided:  Hiunan  users,  external  data  stores 


and  other  application  platforms. 


Figure  6  OSE  Process  Model 


The  GOSIP  protocol  stack  and  OSI  philosophy  are  a 
fundamental  component  of  the  OSE  concept.  Functionally,  an  OSE 
has  three  components:  Information  Transfer,  Information  and 
Information  Processing  as  shown  in  Figure  6.  GOSIP  protocols 
are  concerned  with  the  Information  Transfer  function  of  an 
OSE.  The  GOSIP  transition  must  also  be  consistent  with  other 
OSE  components,  i.e.,  information  and  information  processing. 
In  addition,  the  transition  to  GOSIP  must  be  consistent  with 
the  concurrent  effort  established  in  the  Defense  Message 
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System  Target  Architecture  and  Implementation  Strategy  (TAIS) 
as  part  of  OSE. 

6.  CIM  Standards  Profile 

The  Corporate  Information  management  (CIM)  Technical 
Reference  Model  is  based  on  a  consensus-based  standards 
approach.  The  standards  profile  supports  this  reference  model 
and  directly  addresres  the  OSE  perspective  of  end-to-end 
interoperability.  Figure  7  shows  the  CIM  Standards  Profile 
and  the  relationship  of  GOSIP  to  CIM.  The  following  set  of 
open  systems  interconnection  services  apply. 

•  Program  (Ada,  C) 

•  User  Interface  (X-Windows,  VT) 

•  Data  Management  (RDA,  SQL,  IRDS) 

•  Data  Interchange  (ODA,  RJE,  EDI,  FTAM,  X.400) 

•  Graphics  (NITF,  GKS,  PHIGS) 

•  Network  (X.25,  IEEE  802.3,  Banyan  VINES,  ArcNet,  SNA) 

•  Operating  System  (MS-DOS,  UNIX) 

7.  User  Operating  Environment 

Figure  8  shows  a  set  of  open  systems  interconnection 
inter-computer  services  for  the  DoN  automated  enterprise. 

a.  User  Interface 

The  user  interface  uses  a  Graphical  User  Interface 
(GUI)  such  as  Microsoft  Windows  or  textual  such  as  MS-DOS 
command  line  interaction.  This  interface  is  supported  by  the 
application  software.  This  software  consists  of  generic 
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Mission  Area  implications 
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applications  (i.e.,  E-Mail,  word  processing,  database) 

b.  Program  Sorvicos 

These  services  include  programming  languages  (Ada, 
C,  etc.)  and  language  bindings.  Computer  Aided  Software 
Engineering  (CASE)  environment  and  tools,  and  security  (access 
to  programming  objects). 

c.  User  Interface  Services 

These  services  define  how  users  interact  with  the 
application.  Presentation  determines  the  user  interface 
appearance.  The  tool  kit  defines  objects  such  as  menus, 
scroll  bars,  etc.  used  to  build  an  interface.  The  data  stream 
interface  specifies  a  function  call  interface  to  build 
messages  defined  in  the  encoding  layer.  The  application 
dialogue  coordinates  the  interaction  between  user  and  systems. 
The  subroutine  foundation  builds  components  of  window 
interfaces  such  as  scroll  bars.  Security  defines  the  types  of 
user  access  to  objects  and  functions  used  for  interface 
management . 

d.  Data  Management  Services 

These  services  manage  the  creation  or  use  of  data. 
Directory/dict ionary  services,  facilitate  access  to  metadata, 
allow  access  to  modify  data  rules,  provide  a  set  of  security 
rules  for  location  of  data  in  a  distributed  system.  DataJsase 
management  System  (DBMS)  services  provide  controlled  access 
and  management  of  structured  data.  Distributed  data  provides 
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access  to  and  modification  of  data  in  a  remote  dated>ase. 
Security  includes  control  of  access  to  and  integrity  of  stored 
data. 

e.  Data  Interchange  Services 

These  services  provide  specialized  support  for  the 
interchange  of  data  between  applications.  Document 
interchange  include  specifications  for  encoding  the  data. 
Graphics  data  services  include  device  independent  descriptions 
of  picture  elements.  Product  data  encompasses  data  necessary 
to  describe  technical  drawings/  and  documentation.  Security 
is  used  to  verify  and  validate  interchanges  such  as 
nonrepudiation,  encryption  and  labeling. 

f.  Graphics  Services 

Graphics  services  provide  functions  required  for 
creating  and  manipulating  pictures.  Graphics  management 
includes  display  element  definition  and  object  attribute 
definition.  Security  restricts  access  to  functions  that 
support  the  development  of  graphics  software  and  data. 

g.  Network  Services 

These  services  are  provided  to  support  required 
data  access  and  interoperability  across  networked 
environments.  Data  communications  includes  protocols  for 
reliable,  transparent  end-to-end  transmission  across  networks. 
Distributed  computing  include  specifications  for  extending 
local  procedure  calls  across  a  network.  Personal  Computer 
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(PC)  support  provides  interoperability  with  systems  in  a 
variety  of  operating  systems.  Transparent  file  access  to 
local  and  remote  files  provides  ease  of  use  to  users. 
Security  includes  access  control,  authentication  both  for 
network  users  and  network  management. 

h.  Operating  System  Services 

These  services  operate  and  administer  the 
application  platform.  Also  they  provide  an  interface  between 
application  software  and  the  platform.  Kernel  operations 
provide  services  to  manage  processes  and  execute  programs. 
Command  and  utilities  provide  printing  and  displaying  file 
content.  System  management  defines  and  manages  user  access, 
and  devices.  Security  ensures  data  confidentiality, 
integrity,  access  control  and  availability. 

i.  External  Environment  Interface 

Security  services  and  system  management  overlap 
among  certain  types  of  individual  system  management  functions 
( i . e . ,  KG-8  4 ,  STU-3 ,  Kerberos ) . 

j.  Hardware/Software/External  Environment 

This  environment  is  composed  of  the  collection  of 
hardware  and  software  components  that  provide  the  services 
used  by  application  programs  (i.e.,  CD-ROM,  remote  sensors). 

C.  WAIVERS 

Exemption  from  GOSIP  procurement  requirements,  is 
available  if  it  can  be  clearly  demonstrated  that  there  are 
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significant  performance  or  cost  advantages  to  be  gained  and  is 
in  the  best  interests  of  the  government.  Waivers  may  also  be 
requested  when  functionality  critical  to  an  agency  mission  is 
not  included  in  GOSIP-compliant  products.  Additional 
considerations  include  special  purpose  networks  and  systems 
supporting  network  research  [Boland,  1991].  Waivers  should 
include: 

•  a  description  of  the  existing  or  planned  ADP  system; 

•  a  description  of  the  system  configuration,  identifying  the 
items  for  which  the  waiver  is  being  requested  and  planned 
expansion  of  the  system  over  its  life  cycle; 

•  and  a  justification  explaining  the  disadvantage  caused 
through  conformance  to  the  standard  as  compared  to  the 
proposed  alternative. 

Federal  department  heads  and  agency  heads  (SECDEF,  SECNAV) 
may  approve  waivers  to  FIPS  when:  1)  compliance  with  the 
standard  would  adversely  affect  the  accomplishment  of  the 
mission  of  an  operator  of  a  computer  system,  or  2)  cause  a 
major  adverse  financial  impact  on  the  operator  which  is  not 
offset  by  government-wide  savings.  Waivers  must  be  sent  to 
NIST,  House  of  Representatives  and  Senate  Committees  on 
Government  Operations,  and  must  be  published  in  the  Federal 
Register  and  Commerce  Business  Daily  [Boland,  1991]. 
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V. 


GOSIP  PRODUCT  DBVELOPMBMT  AMD  SUPPORT 


The  transition  to  OSI  is  an  evolutionary  process  and 
dependent  on  GOSIP  product  development  and  availability. 
Unfortunately,  this  situation  requires  extended  periods  of 
heterogenous  protocol  coexistence,  a  condition  not  well 
supported  by  OSI. 

OSI  is  designed  as  a  displacement  technology.  In  fact, 
the  committees  which  produce  OSI  standards  are  very 
careful  neither  to  reference  nor  accommodate  any  non-OS I 
technology.  [Rose,  1992] 

GOSIP  product  acquisition  in  support  of  mission  requirements 
and  within  the  arena  of  Program  Objective  Memorandum  (POM) 
cycles,  while  mandated,  is  extremely  difficult.  Wholesale 
replacement  of  existing  systems  is  both  impractical  and 
unrealistic  given  current  fiscal  restraints  and  a  "right- 
sizing”  environment  [Cooney,  1993].  Technological  upgrades 
are  important  life  cycle  considerations  for  current  systems, 
and  while  it  seems  to  allow  a  window  for  OSI  introduction,  the 
availability  and  inter-operability  stumbling  blocks  exist.  A 
careful  and  purposeful  transition  plan  must  be  devised  for 
each  activity,  with  unique  requirements  and  missions  addressed 
with  respect  to  effectiveness  and  efficiency.  It  is  suggested 
in  much  of  the  transition  literature  that  a  single, 
comprehensive  plan  is  necessary  for  adoption  of  GOSIP.  The 
truth  is  that  the  non-OSI  base  is  growing  at  a  faster  rate, 
and  in  many  cases  non-OSI  systems  have  superior  capabilities 
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than  those  in  the  OSI  market  [Cline,  1993].  Established 
computer  vendors  are  increasingly  abandoning  support  of  OSI 
protocols  altogether. 

IBM  is  pulling  back  on  development  of  OSI  products  because 

of  a  loss  of  customer  interest  in  OSI.  [Helson-Rowe,  1993] 

Nevertheless,  if  a  DoN  information  system  requires  inter- 
computer  connection  outside  of  a  host  device,  then  GOSIP  is 
necessitated.  The  ability  to  comply  with  FIPS  146-1  while 
maintaining  functional  computing  capability  is  a  challenge  for 
DoD  IS  Managers  due  to  the  extensive  investment  in  non-GOSIP 
compliant  systems  and  the  problems  associated  with  GOSIP 
product  availability. 

A.  INSTALLED  BASE 

Federal  agencies  have  a  huge  investment  in  installed 
proprietary  networks.  IBM's  System  Network  Architecture 
(SNA),  DECnet,  Novell's  IPX/SPX  and  AppleTalk  make  up  eighty- 
five  percent  of  the  currently  installed  architectures,  with  1 
in  4  government  computer  networks  based  on  SNA.  The  Internet 
"open"  protocol  TCP/IP  is  making  strong  gains  at  the  expense 
of  older  asynchronous  and  bisynchronous  communications  and  is 
gaining  popularity  as  the  open  standard  of  choice.  Estimates 
expect  TCP/IP  to  hold  twenty-one  percent  of  the  base  by  1994 
[Masud,  1993]. 

Complicating  the  networking  picture  is  that  eighty-two 
percent  of  networks  worldwide  have  three  or  more  protocols. 
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Legacy  systems  often  provide  critical  functions  and  are  not 

£tbandoned  when  new  systems  are  introduced.  This  reality 

provides  the  greatest  stumbling  block  for  open  systems  and 

GOSIP  transition.  Manufacturers  are  not  eibout  to  abandon 

their  loyal  customers  to  embrace  open  systems.  These 

companies  have  a  large  investment  in  their  proprietary 

architecture  and  are  unlikely  to  offer  competition  to  their 

own  sales  as  well  as  dead*-end  their  systems. 

The  software  vendors  won't  want  to  adopt  OSI  as  their 
native  protocol.  IBM  won't.  They  will  continue  to  put 
the  good  stuff  on  SNA.  Knowing  this,  why  would  a  customer 
want  to  migrate  to  OSI?  [Becker,  1992] 

OSI  protocols  also  suffer  from  the  standards  process. 
Companies  are  embracing  TCP/IP  protocols  because  they  are 
developed  on-line,  they  are  open,  and  available  for  free.  The 
ISO  process  is  strictly  controlled  and  excluded  from  the 
public  domain,  and  stringent  certification  requirements  cause 
development  costs  and  schedules  to  skyrocket  [Masud,  1993]. 
The  situation  has  become  a  self-fulfilling  prophecy,  GOSIP 
migration  is  stymied  by  lack  of  product  availability  and  thus 
organizations  become  further  entrenched  in  their  old 
architecture  and  contractors  resist  developing  GOSIP  products 
because  they  are  not  being  bought.  Because  OSI  products  are 
often  more  expensive  and  incompatible  with  the  installed  base 
(thus  making  them  mission  degrading)  contracting  officers  have 
the  flexibility  to  specify  a  second  protocol  and  the  cycle 
repeats  itself. 
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B.  PKOOUCTS 


GOSIP  transition  ultimately  depends  on  products  being 
available  to  meet  the  demand  and  fulfill  operational  and 
legislative  requirements.  The  issues  surrounding  GOSIP 
products  are  compliance,  conformance  and  interoperability 
[Cline,  1992]. 

1 .  GOSIP  Compliance 

Compliance  means  that  a  vendor  has,  to  the  best  of  its 
edjility,  faithfully  implemented  the  specification  for  the  OSI 
standard.  Companies  become  skillful  and  effective  at 
implementing  the  required  protocols  by  implementation 
experience,  and  participation  in  the  standards  process  by 
being  members  of  an  ISO  product  committee.  However, 
compliance  is  subjective  and  not  subject  to  independent 
verification.  Ultimately,  a  vendor's  history  and  committed 
resources  determine  the  degree  of  protocol  compliance. 

2.  GOSIP  Conformance 

Conformance  is  considerably  different  than  compliance, 
it  requires  that  a  product  is  tested  and  shown  to  faithfully 
implement  required  specifications.  This  type  of  product 
assurance  is  overseen  by  the  National  Institute  of  Standards 
and  Technology  (NIST),  which  is  responsible  for  GOSIP 
conformance  tests.  NIST  accredits  GOSIP  conformance  testing 
laboratories  through  the  National  Volunteer  Ladjoratory 
Accreditation  Program  (NVLAP)  and  other  standards  bodies 
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(i.e.,  Corporation  for  Open  Systems  International  and  NIU- 
Form) .  Results  of  product  tests  are  certified  by  the  Joint 
Interoperability  Test  Center  (JITC). 


JITC  is  under  the  Defense  Information  Systems  Agency 
(DISA)  and  the  exclusive  agent  for  GOSIP  conformance 
certification.  JITC  reviews  test  suite  results  and  certifies 
tools  used  in  testing  but  does  not  itself  conduct  conformance 
testing.  Vendors  desiring  their  products  to  be  listed  on  the 
GOSIP  Conformance  Test  Register  are  required  to  pay  for  both 
the  independent  testing  and  the  JITC  certification  [Wilson, 
1992]  . 

3 .  GOSIP  Interoperability 

The  third,  and  potentially  the  most  important 
consideration  is  product  interoperability.  GOS IP-conformant 
products  must  demonstrate  that  they  work  well  with  other 
conformant  products.  This  additional  testing  is  certified  by 
OSINET  of  the  Corporation  for  Open  Systems,  with  products 
listed  in  the  "Interopereibility  Acceptance”  database  and 
beginning  in  the  Summer  of  1993,  JITC  will  test  for 
interoperability  in  corporation  with  the  Standards  Promotion 
and  Application  Group  (SPAG). 

OSINET  is  an  organization  dedicated  to  OSI 
interoperability  testing  and  is  a  member  of  an  international 
consortium  of  OSI  interoperability  test  organizations.  Until 
recently,  OSINET  was  the  only  accredited  US  test  center  and 
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operated  GOSIP  test  suites  for  X.400,  FTAM,  X.500  and  VTP. 
The  OSINET  certification  is  the  most  tangible  and  practical 
measure  of  GOSIP  products  because  it  shows  multi-vendor 
products  will  work  in  concert. 

SPAG  will  provide  additional  product  testing  with  it's 
Process  to  Support  Interoperability  (PSI)  mark.  IBM,  Digital 
Equipment  Corporation  and  Hewlett-Packard  Company  have  teamed 
to  give  vendors  a  formal  mechanism  for  certifying  the 
interoperability  of  their  GOSIP  products.  PSI  testing  for 
X.400  (1984)  and  FTAM  will  be  available  in  late  1993  with 
planned  expansion  for  X.500  and  1988-version  X.400.  This 
increased  opportunity  for  interoperability  testing  is  hoped  to 
improve  the  availaJaility  of  GOSIP  products,  however  OSINET  and 
the  PSI  mark  are  not  mandatory  for  GOSIP  products  [Masud, 
1993] . 

4.  GOSIP  Problem 

Adoption  of  the  GOSIP  standard  would  seem  to 
facilitate  the  production  of  conformant  and  interoperable 
products  in  large  numbers.  Unfortunately,  vendors  find  it 
more  convenient  to  proclaim  compliance,  skip  the  expensive  and 
difficult  conformance  testing  and  go  straight  to 
interoperability  testing  [Cline,  1992].  The  problem  faced  in 
obtaining  these  products  is  that  GOSIP  procurement  is  bound  by 
FIPS  146-1,  Federal  Acquisition  Regulations  (FAR),  and  Federal 
Information  Resource  Management  Regulations  (FIRMR),  which 


44 


combine  to  specify  GOSIP  "conformance" .  Adding  to  the 
problem  is  the  fact  that  government  conformance  certification 
is  not  yet  availed^le  for  some  OSI  components/  including  VT/ 
1988  X.25,  1988  X.400,  CIMP/CMIS,  and  GNMP  [Cline,  1993]. 
Also,  NIST  does  not  require  interoperability  testing,  even 
though  conformance  to  the  standard  does  not  ensure 
interoperability.  While  many  vendors  claim  compliancy  with 
GOSIP,  about  fifty  percent  fail  the  tests  [Messmer,  1992] 

Procurement  and  introduction  of  GOSIP  products  as 
directed  by  the  FIPS  become  quite  difficult  when  there  are  no 
certified  products  available.  There  is  hope  for  the  future  of 
OSI  products  however.  GOSIP  has  narrowed  the  OSI  definitions 
to  clarify  the  interoperability  requirements.  This 
improvement  in  the  standard  and  the  emergence  of  organizations 
committed  to  GOSIP  implementation  has  dramatically  improved 
the  situation  facing  IS  managers.  The  Corporation  for  Open 
Systems  (COS)  has  certified  many  products  which  have  passed 
conformance  tests  and  has  reduced  the  risk  of  obtaining  non- 
interoperable  products.  The  list  of  GOSIP  products  available 
has  quadrupled  in  the  last  year,  however  still  numbering  fewer 
than  twenty  [Becker,  1992].  Additionally,  ORINET,  an 
organization  made  up  of  users,  vendors,  and  regulatory  groups 
involved  in  open  systems  standards  testing,  keeps  a  listing  of 
all  vendors  and  products  that  have  passed  interoperability 
testing.  The  register  currently  lists  165  entries  from 
seventeen  companies  using  sixty-two  products  [Becker,  1992]. 
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Help  can  also  be  elicited  from  an  open  systems 
integration  led>oratory  in  Annapolis  Junction,  Maryland.  Van 
Dyke  and  Associates  has  demonstrated  interoperation  of  OSI 
products  from  more  than  thirty  vendors.  The  lab  will  conduct 
performance  and  functional  analysis,  develop  OSI  solutions  for 
specific  needs,  and  demonstrate  the  interworking  of  OSI  and 
TCP/IP  suites  [Masud,  1993]. 

Vendors  faced  with  a  declining  government  economic 
base  and  an  open  resistance  to  OSI  in  the  commercial  market 
place  have  resisted  development  of  GOSIP  conformant  products. 
In  1992  there  was  only  one  JITC-certified  conformant  1984 
X.400  product  and  no  1988  X.400  versions  available  [Cline, 
1993].  OSI  protocols  have  seemed  increasingly  irrelevant, 
being  overshadowed  by  de  facto  standards  and  proprietary 
dominance.  However,  OSI  can  become  a  dominant  protocol  for 
the  21st  century  if  its  advocates  continue  to  developing 
viable  and  coherent  migration  strategies  which  embrace 
coexistence  with  the  installed  base  [Hall,  1993]. 

C.  THE  OOSIP  INSTITUTE 

There  are  many  supporting  organizations  which  have  aligned 
themselves  with  both  the  Internet  and  the  OSI  communities. 
The  future  of  networking  however,  while  still  unclear,  would 
rationally  be  a  combination  of  the  Internet  installed  base  and 
the  proposed  improvements  offered  by  OSI.  A  promising  future 
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for  standardization  is  the  single  convergency  solution 
proposed  by  The  GOSIP  Institute. 

The  INTERNET  2000  ;  A  Protocol  Framework  to  Achieve  a 

Sxnale  Worldwide  TCP/IP/OSI/CLNP _ Internet  bv _ Year  2000 

proposal  advocates,  "anything  over  anything"  and  calls  for  the 
respective  cononunities  to, 

. . .  put  the  divisions  of  the  past  behind  them  and  join 
together  to  achieve  a  single  Worldwide  Internet.  [GOSIP 
Institute,  1993] 

The  approach  advocated  by  The  GOSIP  Institute  is  based  on 
converging  IP  and  CLNP  to  provide  an  easy  to  understand,  easy 
to  implement,  win-win  environment. 

1 .  Approach 

The  GOSIP  Institute  White  Paper,  version  3.0 
recommends  building  "Internet  2000"  on  the  basis  of  the  TCP/IP 
Internet  de  facto  four-layer  architecture  and  US  GOSIP.  The 
belief  is  that  Application  services  over  Transport  services 
over  Internetwork  over  Subnetworks  will  provide  for  the 
"anything  over  anything"  internetworking  future. 

2 .  Subnetworks  Layer 

The  existing  TCP/IP  Internet  does  not  specify 
subnetwork  technologies.  The  TCP/IP  Internet  approach  allows 
organizations  to  decide  their  own  subnetwork  based  on  their 
own  criteria.  GOSIP  currently  recommends  a  specific  set  of 
subnetwork  technologies:  IEEE  802.3  CSMA/CD,  IEEE  802.5  token 
ring,  X.25  packet  switched  network,  HDLC  point-to-point  links. 


47 


ISDN  digital  telephone  network;  with  future  60SIP  versions 
adding  FDDI  fiber  optic  LAN,  frame  relay  fast  packet  switched 
network,  and  PPP  (point-to-point  protocol). 

GOSIP  requires  agencies  to  select  a  subset  of  the 
subnetwork  technologies  specified  in  order  to  promote 
internetworking.  Current  practices  with  the  TCP/IP  Internet 
and  OS I  communities  are  compatible  at  the  subnetwork  layer  as 
sxibnetwork  technologies  are  permitted  to  be  selected  based  on 
individual  criteria  [GOSIP  Institute,  1993]. 

3 .  Internetwork  Layer 

TCP/IP  Internet  requires  IP  as  the  internetwork 
protocol.  IP  is  being  reworked  to  provide  more  addresses  to 
help  solve  the  large  flat  routing  table  problem.  Currently 
available  improvements  are  TCP  and  UDP  with  Bigger  Addresses 
(TUBA)  and  Classless  Interdomain  Routing  (CIDR).  These  two 
methods  are  not  mutually  incompatible  but  provide  two 
evolutionary  ways  of  dealing  with  IP  address  depletion  while 
still  providing  traditional  IP  and  CLNP  routing.  CIDR 
provides  many  more  addresses  immediately,  delaying  the 
addressing  crisis  until  at  least  the  end  of  the  century,  and 
TUBA  provides  a  means  for  the  OS I /GOSIP  community  to 
interoperate  immediately  with  the  IP  community  through  dual 
stacks. 

The  importance  of  achieving  a  single  Worldwide 
Internet  based  on  a  single  “convergence"  internet  protocol  and 
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supported  by  a  single  suite  of  routing  is  recognized  by  both 
communities.  The  availability  of  CIDR  and  TUBA  will  allow 
timely  deliberation  to  occur,  so  that  all  internet  protocol 
features  and  routing  protocol  features  required  by  the  next 
generation  IP  are  included  in  the  protocol  which  is  selected. 
If  a  new  IP  "next  generation"  protocol  with  significant  new 
functionality  does  in  fact  emerge  from  the  current  process, 
then  the  new  protocol  should  become  both  "IPng"  and  "CLNPv.2", 
and  that  both  the  Internet  and  OSI  communities  should  adopt 
the  new  protocol  as  the  single  internetwork  protocol  for  the 
worldwide  community. 

GOSIP  requires  CLNP,  however  functionally  CLNP  is  just 
IP  with  lots  of  addresses.  CLNP  solves  the  large  flat  routing 
tcible  problem  by  having  lots  of  addresses  available,  so  that 
end-systems  may  be  assigned  two  (or  more)  addresses,  at  least 
one  of  which  is  hierarchical.  The  CLNP  is  attractive  in  the 
medium  term  when  teamed  with  CIDR  and  TUBA  because  IP 
addresses  from  the  new  CIDR  distribution  can  interoperate  with 
older  IP  hosts.  The  CIDR  and  TUBA  recommendations  would 
produce  a  Worldwide  Internet  that  provides  both  CLNP  and  IP 
routing. 

New  TCP/IP  Internet  hosts  should  implement  TCP  over 
CLNP  in  addition  to  IP,  while  older  hosts  should  automatically 
be  assigned  a  new  Internet  NSAP  address  to  use  whenever  they 
decide  to  add  CLNP  capeibility.  Legacy  systems  could  continue 
to  use  traditional  IP  routing  into  the  medium  term,  but  the 
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long-term  view  would  be  to  phase  it  out  after  everyone  has 
converted  to  the  new  convergence  protocol.  Achieving 
worldwide  "dial tone"  (i.e.,  routing)  is  the  important  part  of 
this  approach,  because  it  is  the  expensive  part  due  to  the 
large  infrastructure  investment  that  it  represents.  Once 
worldwide  routing  is  in  place,  everyone  new  who  joins  the 
Internet  will  be  able  to  support  two  (or  more)  Transport 
stacks  economically. 

The  Internetwork  Layer  proposal  is  implemented  within 
the  existing  Internet.  CLHP  and  its  associated  routing 
protocols  are  based  on  and  improve  upon  IP  experience  and 
lessons  learned,  in  that  they  support  autoconfiguration  (i.e., 
dyn£unic  network  address  learning).  The  CLNP  and  associated 
routing  protocols  have  already  been  implemented  by  the  major 
vendors,  and  are  currently  being  deployed  in  the  major 
Worldwide  Internet  provider  networks.  Everyone  already  knows 
how  to  do  global  longest-prefix  routing,  which  is  the  basis  of 
IP  and  CLNP  routing  protocols.  Addresses  would  be  recognized 
within  GOSIP  and  the  other  worldwide  OSI  bodies,  but  would  be 
assigned  by  Internet.  The  worldwide  backbone  and  regional 
networks  would  define  a  routing  hierarchy  and  addressing 
structure  to  solve  the  routing  table  problem  by  assigning 
administrative  authority  identifiers  and  routing  domain 
addresses  to  regional  networks,  and  routing  domain  and  area 
addresses  to  organizational  networks  [GOSIP  Institute,  1993). 
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4.  Transport  Services  Layer 


TCP/IP  Internet  currently  requires  that  Transport 
Services  be  provided  by  TCP  and  UDP,  however  there  are  no 
formal  service  specifications.  The  Sockets  and  TLI  interfaces 
are  de  facto  standard  progreun  interfaces  to  the  Transport 
service.  GOSIP  requires  that  TP4  be  used  to  provide  the 
Connection-oriented  Transport  Service,  and  allows  the  use  of 
CLTP  (Connectionless  Transport  Protocol,  equivalent  to  UDP)  to 
provide  the  Connectionless  Transport  Service  as  an  option  (ISO 
8072  and  CCITT  X.214).  The  X/Open  XTI  interface  is  the  de 
facto  standard  program  interface. 

The  Internet  2000  proposal  for  the  Transport  Services 
Layer  is  a  three-part  recommendation.  First,  TCP/IP  Internet 
should  continue  to  provide  TCP  and  UDP  services  at  Sockets  and 
TLI  interfaces,  and  GOSIP  should  continue  to  provide  the  OS I 
connection-oriented  and  connectionless  Transport  services  at 
XTI  interfaces  using  TP4  and  CLTP.  This  first  part  of  the 
recommendation  simply  means  that  both  TCP/UDP  and  TP4/CLTP 
Transport  protocol  suites  should  be  allowed  in  the  near  term. 
The  type  of  Transport  protocol  entity  bound  to  each  NSAP 
address  should  be  identified  in  the  address.  Transport 
addresses  are  already  structurally  equivalent  between  the  two 
communities . 

Second,  the  GOSIP  community  should  adopt  the  Internet 
RFC  1006  OSI/TCP  Coexistence  Stack  (i.e.,  TPO  over  TCP)  as 
well  as  the  TUBA  stack  as  legitimate  options  to  the  TP4/CLNP 
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mandatory  stack,  and  should  carry  the  concept  a  step  further 
by  defining  all  the  legitimate  ways  that  Application  Services 
from  either  suite  may  call  upon  Transport  Services  from  the 
other  suite.  A  Transport  entity  that  wants  to  reach  an  NSAP 
address  bound  to  a  different  type  of  Transport  stack  may  still 
be  able  to  interoperate  if  it  knows  the  NSAP  address  of  an 
appropriate  Transport  switch  (called  a  "Transport  bridge" 
within  Internet  and  a  "Transport  interworking  unit"  within 
ISO).  The  IETF,  in  collaboration  with  ANSI,  IEEE  and  ISO, 
should  develop  and  specify  the  legitimate  ways  of  calling  upon 
and  interoperating  among  these  Transport  stack  combinations  in 
the  near  term.  IEEE  POSIX  is  currently  developing  a  Detailed 
Network  Interface  (DNI)  that  supports  both  Sockets  and  XTI 
(i.e.,  an  application  can  run  directly  over  one  or  the  other 
Transport  interface)  as  well  as  a  Simple  Network  Interface 
(SNI)  that  hides  the  details  of  the  Transport  interface.  This 
work  should  be  accelerated  and  brought  to  completion,  and  its 
use  should  be  recommended  by  both  communities. 

Third,  for  the  long  term,  both  communities  should  work 
together  to  develop  the  next-generation  Transport  protocol, 
and  define  the  ways  that  it  can  run  over  CONS,  CLNS,  IP 
service,  and  subnetwork  services  directly  (i.e..  Transport 
directly  over  LANs,  MANs,  and  connection-oriented  WANs).  Note 
that  TCP  and  TP4  are  both  based  on  the  same  generation  of 
technology,  i.e.,  the  1970s.  TP4  is  more  efficient  and  faster 
than  TCP  with  checksum  turned  off,  but  may  run  slower  in 
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actual  operation  due  to  the  choice  of  a  heavy  duty  mandatory 
checksiun  and  due  to  improved  operational  procedures  defined 
for  TCP.  By  the  year  2000,  rate-based  and  selective 
retransmission  Transport  technology  will  be  needed  to  provide 
isochronous  service  over  high-speed,  mostly-reliedjle  networks 
such  as  LANs,  frame  relay/ISDN,  SMDS,  and  ATM/BISDN. 

There  is  no  reason,  with  available  technology,  to 
perpetuate  the  "two-community"  divisiveness  into  the  next 
century.  The  two  groups  should  join  together,  with  either  one 
taking  the  lead  or  both  working  together  over  the  Internet,  to 
define  a  single  protocol.  This  problem  should  be  used  as  an 
opportunity  to  develop  a  pilot  project  to  find  out  how  the 
IETF,  X3S3,  and  SC6  should  work  together  in  the  future.  The 
proposal  for  doing  a  combined  lETF/ANSI/ISO  future  transport 
standard  really  is  a  perfect  test  case  for  the  two  communities 
working  together.  IETF  should  just  say  how  they  would  like  to 
work  on  the  project,  and  see  if  the  ANSI/ISO  process  won't 
accommodate  the  best  way  of  working.  Proprietary  transport 
services  are  also  provided  in  this  layer  via  support  of 
Sockets  and  XTI  program  interface  specifications,  as  well  as 
through  transport  interworking  schemes  specified  by  those 
vendors.  Each  vendor  would  specify  its  own  "three-legged"  (or 
more-legged)  architecture  under  the  common  Sockets  and/or  XTI 
program  interfaces.  This  Transport  Services  Layer  component  of 
the  Internet  2000  Framework  proposal  is  a  win-win  situation 
because  both  communities  would  continue  to  support  their 
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defined  Transport  services,  so  both  would  be  happy  in  that 
respect.  Application  services  written  to  a  standard  Sockets 
or  XTI  specification  would  run  over  both  stacks,  and  both 
communities  would  converge  to  a  common  next-generation 
Transport  protocol  running  over  the  next-generation 
convergence  stack  or  directly  over  LANs,  MANs,  or  Am/BISDN 
service  by  Year  2000.  Then  there  will  be  a  common,  single 
Worldwide  Internet /Networking  community  up  through  the 
Transport  layer  [GOSIP  Institute,  1993]. 

5.  Application  Services  Layer 

TCP/IP  Internet  currently  plugs  its  Application 
services  such  as  FTP  and  TELNET  directly  into  Transport 
services.  The  virtue  of  this  approach  is  simplicity. 
OSI/GOSIP  uses  a  three-upper-layer  stack  to  provide  its 
Application  services.  Session  Layer  is  used  to  provide 
dialogue  control  (primarily,  graceful  close).  Presentation 
Layer  is  used  to  identify  alternative  encodings.  Application 
Layer  is  built  up  in  standard  ways  called  "application 
contexts"  using  building  blocks  called  "application  service 
elements  (ASEs)"  (e.g.,  Association  Control  Service  Element 
(ACSE)  to  do  call  control.  Directory  User  Agent  (DUA)  Service 
Element  to  look  up  information  in  the  X.500  Directory).  The 
virtue  of  this  approach  is  interworking  flexibility,  but  at  a 
cost  of  complexity.  The  future  OSI  Upper  Layer  Architecture 
now  under  development  may  become  fully  recursive  edsove  the 
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Transport  Service,  i.e.,  basically  one  layer  with  a  specified 
three-layer  internal  organization,  like  the  OSI  Network  Layer 
is  now. 

The  Internet  2000  proposal  for  Application  Services 
Layer  recommends  that  both  communities  keep  their  current 
methods  of  providing  Application  services.  This  means 
specifically  that  OSI  would  continue  to  look  into  how  to 
streamline  its  upper  layers.  To  interwork  with  each  other, 
both  communities  should  use  Application  gateways  (i.e.,  dual 
Application  service  implementations  with  mapping  between 
them),  and  both  communities  should  provide  their  Application 
services  over  dual  Transport  stacks.  OSI  Presentation 

addresses  of  the  form  (NULL,  NULL,  T-selector,  NSAP-address ) 
may  be  used  by  both  sides  to  address  applications  seen  through 
gateways.  The  advantage  of  using  this  form  is  that  it  is 
already  an  X.500  Directory  attribute  type. 

Both  communities  should  continue  to  roll  out  new 
Application  protocols  such  as  SNMP2,  PEM,  MIME,  X. 400-1988, 
X. 435-1992  (PEDI),  X. 500-1993,  ODA,  SGML,  Distributed 
Transaction  Processing,  Knowledge  Discovery  (Gopher),  World 
Wide  Web  (WWW),  Wide  Area  Information  Server  (WAIS). 
Additionally,  development  of  an  "open  RPC"  (remote  procedure 
call)  standard  between  IETF  and  ISO  SC21  is  crucial.  The 
ISO/CCITT  standardization  process  should  increasingly  take 
account  of  the  principles  and  methods  of  the  Internet 
standardization  process,  principally: 
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•  electronic  "groupware"  distribution,  discussion,  and 
development  of  draft  standards,  together  with  the 
principle  of  "implement  first,  standardize  second"  (this 
process  is  known  in  the  Internet  community  as  "rough 
consensus  and  running  code"); 

•  providing  specifications  and  software  implementations  on¬ 
line  and  at  low  or  no  cost.  The  Internet  should  continue 
to  take  on  the  task  of  discussing,  developing  and 
deploying  the  infrastructure  needed  to  support  new 
networking  standards.  Ultimately,  the  marketplace  will 
decide  what  works. 

To  promote  application  portability  and  interworking, 
both  communities  should  continue  to  support  the  development 
and  use  of  consortia-defined  or  IEEE  POSIX  open  systems 
environments,  APIs  and  protocols.  Continued  support  for 
standards  running  TCP/IP  Internet  applications  over  OSI/CLNP 
Internet  stacks,  such  as  X  Window  over  the  OSI  skinny  stack, 
SNMP  over  CLNP,  and  NFS  over  CLTP  or  over  a  connectionless 
ACSE  skinny  stack  is  necessary  for  uninterrupted 
functionality. 

Proprietary  schemes  found  in  legacy  systems  really 
begin  to  proliferate  in  this  Application  Services  layer, 
raising  important  issues  for  users.  It  is  important  to  find 
a  way  for  users  to  benefit  from  the  competition  for  best 
applications  features  and  functionality  while  still  achieving 
a  maximum  of  applications  interoperability  and  portability. 
The  consortia-defined  and  IEEE  API  standards  are  key  to  the 
solution.  All  operating  systems  environments,  (including 
Windows  NT,  OS/2,  SunOS,  Solaris,  SCO,  Univel,  OSF/1, 
Macintosh)  should  support  the  open  systems  environment  (OSE) 
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functional  sta-'dards  agreed  by  the  three  regional  workshops: 
NIST  OSE  Implementors  Workshop  (OIW),  European  Workshop  for 
Open  Systems  (EWOS),  and  Asia  and  Oceania  Workshop  (AOW). 
Procurement  profiles  such  as  GOSIP  should  not  even  consider 
adopting  anything  other  than  International  Standardized 
Profiles,  harmonized  workshop  agreements,  or  convergence 
standards  worked  out  between  ISOC,  ISO,  and  CCITT,  except  as 
a  consensus  approach  to  promoting  convergence  that  has  been 
coordinated  with  all  interested  parties  [GOSIP  Institute, 
1993] . 
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VI. 


TRAMSITIOM  STRATEGIES 


The  Brooks  Act  (Public  Law  89-306)  established  the  Federal 
Information  Processing  Standards  (FIPS)  under  the  direction  of 
the  Secretary  of  Commerce  and  NIST.  The  GOSIP  requirements 
(FIPS  146)  have  been  mandatory  for  use  in  solicitations  and 
contracts  since  15  August,  1990  and  GOSIP  version  2  (FIPS  146- 
1)  as  of  3  October  1992. 

The  Navy  currently  maintains  requirements  in  support  of 
Don  GOSIP  transition  goals  [DoN,  1993]: 

•  Implement  GOSIP  standards  whxch  are  technically  feasible; 

•  Insure  that  GOSIP  standards  are  operationally  sufficient; 

•  Implement  solutions  that  are  affordable  within  budget 
cycles; 

•  Maintain  consistency  with  ongoing  DoD  programs  such  as 
other  Services  GOSIP  plans,  C4I  for  the  Warrior,  Corporate 
Information  Management  (CIM)  efforts.  Defense  Information 
Systems  Network  (DISN),  Defense-wide  Information  System 
Security  Program  (DISSP),  Integrated  Tactical-Strategic 
Data  Network  (ITSDN),  Defense  Information  Infrastructure 
(DII),  and  Defense  Message  System  (DMS); 

•  Support  both  tactical  and  non-tactical  communities; 

•  Provide  near-term  capeibility  with  minimal  disruption  to 
current  opercvions; 

•  Provide  a.nformation  transfer  service  transparent  to  the 
operator  over  common  user  networks. 

Transition  from  the  installed  base  to  GOSIP  standards  must 
progress  through  three  distinct  phases:  non-COSIP  dominance, 
coexistence,  and  GOSIP  dominance.  Currencly,  proprietary 
standards  make-up  the  majority  of  government  systems. 


Initially,  GOSIP  pilot  subnetworks  need  to  be  established 
where  the  mixing  of  standards  will  create  an  environment  of 
coexistence.  The  length  of  the  coexistence  period  will  be 
determined  by  the  availability  and  maturity  of  GOSIP  products. 
The  move  to  a  fully  GOSIP  compliant  system  will  occur  if  and 
when  the  functionality  of  the  GOSIP  products  exceeds  the 
proprietary  functionality  to  such  a  degree  as  to  make  it  cost 
effective  to  replace  existing  systems.  The  limiting  factor  in 
the  GOSIP  development  is  thus  inherent  in  the  management  of 
the  coexistence  and  the  methods  available  to  create  the 
partnership  between  standards  [DoN,  1993]. 

A.  MON-GOSIP  DOMINANCE 

In  spite  of  the  GOSIP  requirements,  the  DoD  is  in  a 
position  of  proprietary  networking  dominance.  Communications 
are  accomplished  through  disjointed  and  non-interoperable 
networks.  Currently  messaging  needs  are  satisfied  by  NTS, 
AUTODIN  of  the  DCS,  and  DDN.  Secret  general  service  end- 
systems  achieve  interoperability  through  the  DDN's  Defense 
Secure  Network  1  (DSNET  1),  Top  Secret  Worldwide  Military 
Command  and  Control  (WWMCCS)  end-systems  use  DSNET  2,  and  Top 
Secret  Sensitive  Compartmented  Information  (TS/SCI)  end- 
systems  communicate  through  DSNET  3.  Tactical  computers 
provide  a  pathway  to  connect  these  systems  by  interfacing  with 
the  DDN  [Don,  1993]. 
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The  Defense  Integrated  Secure  Network  (DISNET)  will 
interconnect  the  three  DSNET  systems  and  allow  subscribers  to 
access  any  network  with  a  single  connection.  Application 
layer  gateways  currently  provide  interoperability  bridges 
between  legacy  systems  and  new  protocols.  Use  of  these 
gateways  offers  a  path  to  a  single  operating  environment  and 
coexistence  among  heterogenous  systems. 

B.  COEXISTENCE 

There  is  a  strategic  imperative  to  provide  application 
infrastructure  solutions  to  allow  the  coexistence  of:  JANAP 
128  (DoD  AUTODIN  message  format),  AGP  127  (NATO  AUTODIN 
message  format),  DDN  SMTP/RFC-822  (DDN  message  protocol),  1984 
and  1988  X.400,  Defense  Message  System  MSP/X.400,  and  AGP  123 
(DoD  common  message  format)  systems.  The  installed  base  of 
entrenched  users  must  transition  gradually  to  the  modern 
architecture,  with  the  new  infrastructure  flexible  enough  to 
absorb  new  products  and  technological  advances.  Coexistence 
must  be  built  into  DoN  application  infrastructure,  not  a 
wholesale  reaction  to  implement  GOSIP  as  a  replacement 
technology  [DoN,  1993]. 

The  cornerstone  of  coexistence  is  the  widespread 
implementation  of  the  Defense  Message  System  (DMS).  DMS  will 
employ  GOSIP  protocols,  which  will  provide  the  base  for 
eventual  GOSIP  transition.  Legacy  systems  can  then  be 
tailored  to  meet  operational  requirements  via  gateways  and 
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routers  so  that  all  or  part  of  the  architecture  is  absorbed 
into  the  system.  Older  systems  will  be  able  to  interoperate 
with  GOSIP  systems  with  OSI  and  proprietary  stacks  coexisting 
in  the  network.  Because  of  the  costly  overlap  of  existing 
systems  and  GOSIP  systems,  only  the  latest  and  proposed 
protocols  should  be  implemented  (i.e.,  1988  X.400). 

Multiple  protocol  connection  gateways  are  the  tools  by 
which  coexistence  will  be  achieved.  This  approach  allows 
backward  interoperability  with  legacy  systems,  while  allowing 
GOSIP  transition  to  progress  with  minimum  disruption  of 
operations.  This  modular  evolution  also  allows  for 
flexibility  as  technology  and  standards  evolve  [DoN,  1993]. 

1.  Evolutionary  Transition 

The  move  into  and  through  network  protocol  coexistence 
can  be  accomplished  using  one  of  six  transition  strategies 
using  GOSIP  compliant  products.  Information  systems  planners 
must  assess  individual  needs  of  their  organizations  in  order 
to  merge  current  proprietary  networks  into  larger  GOSIP  based 
networks . 

a.  Parallel  Networks 

•  Parallel  networks  involve  concurrent  support  of 
multiple  autonomous  computer  networks. 

•  This  unconnected  system  works  well  where  isolated 
groups  do  not  need  to  interoperate  and  where  a  single  user 
does  not  access  multiple  network. 
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•  InteropereUsility  is  not  enhanced  in  this  strategy 
and  duplicate  network  functions  and  staffing  makes  this 
approach  very  costly. 

•  Multiple  systems  of  this  type  are  likely  to  occur 
when  unrelated  commands  are  collocated. 

b.  Bottom-up  Integration 

•  Bottom-up  integration  involves  substituting  GOSIP 
lower  layer  protocols  (layers  1-3)  for  proprietary  protocols. 

•  This  physically  connected  system  allows  for 
resource  sharing  (i.e.,  printers)  and  is  relatively 
inexpensive . 

•  Interoperability  of  data  and  applications  is  not 
achieved  in  this  approach  with  each  node  remaining  isolated. 

•  Simple  LANs  of  this  type  are  useful  when  there 
are  very  few  nodes  in  close  proximity  and  there  is  no 
requirement  to  communicate  outside  the  command. 

c.  Multiple  Protocol  Routing  and  Bridging 

•  Multiple  Protocol  Routing  and  Bridging  consists 
of  a  single  computing  system  concurrently  supporting  multiple, 
coexisting  protocols. 

•  This  approach  offers  a  solution  for  networks 
where  it  is  impractical  or  impossible  to  standardize  on  a 
single  protocol.  An  example  includes  LAN  routers  which 
simultaneously  support  GOSIP,  TCP/IP  and  SNA  communication 
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protocols  or  LAN  bridges  tying  two  or  more  physically 
different  LANs  into  one  logical  L7^. 

•  The  multiple  protocol  stacks  support  a  gradual 
integration  of  GOSIP  protocols  into  an  existing  environment. 
However,  this  approach  only  provides  interoperability  to  like 
protocols,  and  does  not  provide  any  conversion  function 
between  different  protocols. 

•  For  organization  with  extensive  investment  in 
hardware  and  software  and  require  connection  to  external 
networks  but  do  not  share  applications,  this  approach  offers 
the  connectivity  but  does  not  enhance  interoperability. 

d.  Top-down  Transition 

•  Top-down  transition  implements  GOSIP  applications 
over  an  existing  network.  Applications  such  as  FTAM  and  X.400 
would  be  used  over  the  existing  network  by  using  a  common 
transport  layer  interface. 

•  Implementing  GOSIP  applications  allows  for 
international  interoperedaility  and  communication  with  any  OSI 
system  via  gateways. 

•  Drawbacks  to  this  proposal  are  that  a  mixed 
protocol  environment  of  this  type  may  not  be  interoperable 
with  a  purely  GOSIP  environment  due  to  the  differing  transport 
layers  and  the  number  of  GOSIP  systems  available  to  "talk  to" 
are  limited. 
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•  Organizations  anticipating  the  replacement  or 
upgrading  of  hardware  may  want  to  take  advantage  of  the 
improved  functionality  of  GOSIP  applications  in  advance  of 
total  interoperability. 

e.  Implication  Gatenrays 

•  Application  gateways  operate  at  the  Application 
Layer  and  typically  use  application  level  software  to 
translate  proprietary  applications. 

•  Gateways  utilize  a  "mapping"  process  that 
requires  significant  processing  time  and  resources.  This 
strategy  is  good  in  those  situations  where  response  time  is 
not  critical.  Proprietary  applications  remain  in  place  and 
the  phased  approach  minimizes  communications  disruptions. 

•  This  approach  is  not  suitable  for  bulk  transfers 
and  interactive  sessions  due  to  the  excessive  processing  time 
required  for  translation. 

•  Organizations  that  have  unique  applications  may 
find  this  approach  useful  if  rewriting  the  code  would  be 
impracticable  and  they  do  not  require  real  time 
interoperability . 

f.  Hybrid  Networks 

•  Hybrid  networks  consist  of  the  implementation  of 
a  combination  of  transition  strategies.  This  approach  may  be 
appropriate  for  networks  that  may  require  linking  previously 
isolated  islands  of  proprietary  computing. 
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•  This  combination  allows  for  the  "best"  solution 
to  be  used  on  a  case  by  case  basis. 

•  While  hybrid  networks  are  extremely  flexible  they 
have  limited  interoperability  and  without  careful  planning  can 
exacerbate  the  problem  of  proprietary  disconnect. 

•  Commands  that  have  many  highly  specialized 
networks  but  require  common  word  processing  and  E-Mail 
services  may  interconnect  portions  of  their  networks  using 
this  strategy. 

2 .  DoD  Transition 

The  Department  of  Defense  (DoD)  has  taken  a  leading 
role  in  the  evolution  of  networking.  The  Defense  Advanced 
Research  Projects  Agency  (DARPA)  has  been  instrumental  in 
network  research.  The  DoD  issued  a  GOSIP  policy  statement  in 
July  1987,  announcing  plans  to  adopt  FIPS  146  and  begin 
transitioning  to  GOSIP  protocols.  In  June  1988  the  DoD  issued 
a  plan  for  implementing  the  policy.  OSI  transition, 
interoperability  issues,  and  proposed  approaches  were 
intentionally  left  generic.  Accordingly,  any  DoD  approach  to 
transition  may  be  used,  particularly  when  there  is  functional 
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existing  DoD  protocols  needs  to  provide  for  the  expected  life 
of  installed  systems. 

The  DoD  transition  to  the  OS I  architecture  is 
concerned  with  both  implementing  OS  I  and  providing  interim 
DoD/OSI  interoperability  until  OSI  implementation  is  complete. 
Implementation  deals  specifically  with  deploying  GOSIP 
protocols  in  existing  or  future  DoD  networks. 
Interoperability  provides  a  capability  for  the  military 
standard  protocols  on  existing  networks  to  coexist  and 
communicate  with  OSI  protocols  being  introduced.  The  approach 
to  transition  is  multi-faceted,  including:  1)  developing  a 
stack  of  OSI  protocols  on  top  of  DoD's  TCP/IP  using  the  ISO 
Development  Environment  (ISODE),  2)  having  both  protocols  co¬ 
exist  on  a  particular  host  (dual  protocol  hosts)  and 
converting  from  one  Application  Layer  protocol  to  another 
(Application  Layer  gateway),  3)  supporting  both  DoD  IP  and 
CLNP  at  the  network  layer  (multi-protocol  router)  [Boland, 
1991] . 

a.  ISODE 

The  DoD  protocol  stack  and  the  OSI  protocol  stack 
are  functionally  similar;  therefore,  it  is  possible  to  build 
protocol  implementations  with  a  mixture  of  DoD  and  OSI 
protocols  in  the  stack  (mixed  stack). 

The  ISODE  (ISO  Development  Environment)  is  a  UIJIX 
based  public  domain  software  package  that  includes  the  OSI 
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Application,  Presentation  and  Session  layers.  The  ISODE  runs 
over  the  Transmission  Control  Protocol  (TCP).  Using  ISODE, 
OS  I  applications  can  run  in  a  DoD  networking  environment  using 
DoD  hosts.  The  disadvantage  of  this  approach  is  that  an  end- 
system  can  communicate  only  with  an  end-system  that  has  the 
same  mixed  protocol  stack.  This  alternative  may  be  useful  as 
a  research  or  education  tool  during  the  transition  period. 
The  ISODE  software  includes  the  MHS,  FTAM,  Directory  Services, 
and  VT  applications. 

POSIX  (Portable  Operating  System  for  Computer 
Environments)  is  a  standard  specification  for  UNIX-like 
operating  systems.  Efforts  are  underway  by  University  of 
Pennsylvania  to  put  additional  functionality  into  ISODE  and  to 
make  ISODE  POSIX-compliant  [Boland,  1991]. 

Jb.  DoD-OSI  Multiprotocol  Routers 

In  order  for  DoD-OSI  internetworking  to  occur,  it 
is  necessary  to  provide  OSI  hosts,  on  a  local  area  or  wide 
area  network.  Since  the  DoD  IP  and  OSI  CLNP  are  similar  in 
functionality  and  protocol  structure,  multiprotocol  routers 
are  a  viable  alternative.  The  availability  of  multiprotocol 
routers  would  reduce  the  number  of  components,  and  therefore 
presumably  reduce  the  cost  and  complexity  for  DoD  LANs  that 
are  composed  of  a  mixture  of  DoD  and  OSI  protocol  hosts, 
allowing  the  use  of  DoD  protocols  in  areas  where  OSI  protocols 
are  not  yet  mature. 
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In  either  the  DoD  or  OSI  protocol  architectures, 
Internet  Protocol  (IP)  or  CLNP  performs  routing  functions  to 
connect  nodes  on  different  networks.  A  DoD/OSI  multiprotocol 
router  is  a  device  that  is  eJsle  to  distinguish  between  the  DoD 
and  OSI  internetwork  protocol  data  units.  When  a  packet 
arrives  at  an  intermediate  system,  a  network  layer  protocol 
identification  field  is  checked  and  then  the  packet  is  passed 
to  the  appropriate  module  (either  DoD  IP  or  OSI  CLNP)  [Boland, 
1991] . 

c.  Dual  Protocol  Hosts  and  Application  Gateways 

A  dual  protocol  host  has  the  complete  OSI  amd  DoD 
protocol  suites  available  as  part  of  its  networking 
capabilities.  A  user  of  such  a  host  would  have  the  option  of 
invoking  DoD  protocols  or  the  analogous  OSI  application 
protocols.  A  dual  protocol  host  can  be  used  directly  by  users 
with  accounts  to  communicate  to  any  OSI  or  DoD  destination. 
It  can  also  be  used  as  a  staging  point  for  manual 
interoperation  between  a  host  that  has  only  DoD  protocols  and 
a  host  that  has  only  OSI  protocols. 

An  Application  Layer  gateway  is  a  dual  protocol 
host  which  contains  a  conversion  module  residing  at  the 
Application  Layer  of  each  protocol  stack.  The  module  performs 
the  semantic,  syntax,  and  service  transformation  required  for 
the  protocol  conversion. 
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The  OSI  FTAM  and  MHS  protocols  are  candidates  for 
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Figure  9  Gateway  Architectural  Model 

such  a  gateway.  The  NIST  has  developed  and  tested  prototypes 
of  a  gateway  connecting  the  DoD  SMTP  and  the  OSI  MHS 
protocols,  and  a  gateway  connecting  the  DoD  FTP  and  OSI  FTAM 
protocols.  NIST  also  plans  to  provide  an  MHS-SMTP  gateway  as 
an  FTS-2000  service.  These  efforts  demonstrate  the  viability 
of  a  relatively  efficient  means  of  interoperation  between 
systems  based  on  TCP  and  OSI  based  systems.  Gateways  are 
designed  so  that  users  are  required  to  have  minimal  knowledge 
of  a  remote  protocol.  Figure  9  illustrates  how  the  SMTP-MHS 
and  the  FTP-FTAM  gateways  match  protocols  [Boland,  1991]. 
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3.  Military  Considerations 

The  DoD  transition  to  60SIP  must  also  consider  the 
functional  capabilities  necessary  for  tactical  operations 
because  currently  available  OS  I  standards  lack  necessary 
military  considerations.  Military  enhancements  to  GOSIP  at 
each  OSI  layer  must  be  considered  in  implementing  a  transition 
strategy  and  choosing  products  during  the  coexistence  period. 

a.  Application  Layer 

The  Message  Handling  System  should  be  specified 
with  the  optional  smart  duplicating/splitting  procedure  to 
provide  some  multicast  capability.  Granularity  should  be 
provided  through  the  Secure  Data  Network  System  Message 
Security  Protocol  combined  with  the  Key  Management  Protocol  as 
specified  by  the  security  profile.  Additionally,  the  File 
Transfer  and  Access  Management  and  Virtual  Terminal  protocol 
need  to  have  additional  security  mechanisms  added  to  protect 
passwords  and  systems  access  [DoN,  1993]. 

b.  Presentation  Layer 

No  additional  considerations. 

c.  Session  Layer 

Session  layer  protocols  should  use  the  unlimited 
data  size  option  specified  in  version  2  of  the  ISO 
specification.  Negotiation  capabilities  of  the  Session  layer 
can  be  expanded  to  provide  Quality  of  Service  negotiation 
[Don,  1993]. 
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d.  Transport  Layer 

This  layer  should  be  augmented  with  additional 
technologies  developed  within  DoD  Internet  to  give  improved 
performance,  a  reliable  multicast  protocol  at  the  network 
layer,  and  security  mechanisms  [DoN,  1993]. 

e.  Network  Layer 

This  layer  should  be  augmented  with  additional 
protocols  to  support  a  best  effort  multicast  protocol  and 
security  mechanisms  [DoN,  1993]. 

f.  Data  Link  Layer 

Products  shoulc  be  expanded  through  additional 
protocols  to  support  tactical  needs  for  security  and  forward 
error  detection/correction  to  be  used  with  spread  spectrum 
techniques.  Protocol  augment?*tion  such  as  the  32  bit  checksum 
field  can  signif leant j y  improve  the  data  integrity  for 
tactical  systems.  Additionally,  it  should  include  the 
existing  tactical  multicasting  systems  as  subnets  within  the 
link  layer  [DoN,  1993]. 

g.  Physical  Layer 

No  additional  considerations. 

C.  GOSIP  DOMINANCE 

Implementation  of  GOSIP  protocols  to  the  Defense 
Information  System  Network  (DISN)  will  mark  the  final 
transition  to  a  truly  GOS IP-compliant  internetworking  system. 
Product  maturity  and  availability  will  allow  for  widespread 
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replacement  of  legacy  systems  with  gateways,  routers  and 
bridges  remaining  in  place  until  all  systems  can  be 
transformed  to  GOSIP  protocols.  However,  the  expectation  that 
all  government  computers  will  be  interconnected  via  a  single 
standard  is  remote.  There  will  always  be  systems  which  will 
not  interconnect  with  other  systems.  Ultimately,  a  management 
decision  based  on  a  strategic  plan  for  the  individual 
organization  will  determine  the  necessary  level  of 
connectivity.  A  move  to  GOSIP  protocols  must  not  overshadow 
the  operational  requirements  f  a  system.  As  functional 
deficiencies  within  GOSIP  are  identified  and  corrected  in 
follow-on  standards  the  occurrenc  waivers  to  GOSIP  will  be 
reduced.  However,  exceptions  to  standards  will  not  be 
eliminated  as  long  as  DoN  transition  goals  contain  vague 
language  such  as:  "affordable";  "operationally  sufficient"; 
and  "minimal  disruption" . 
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VII. 


COMCLUSIOIIS 


A.  SUMMARY 

The  key  to  achieving  information  transfer  transparency  in 
a  multi-vendor  environment  lies  in  implementing  information 
technology  products  based  on  standard  protocols. 
Implementation  of  standards  encibles  inter-operability  by  using 
a  common  basis  for  information  transfer.  The  failure  of  OSI 
and  thus  GOSIP  to  effectively  transition  into  the  mainstream 
is  that  there  are  few  OSI  commercial  off-the-shelf  (COTS) 
products  available.  Those  products  come  from  only  a  few 
vendors.  Questions  arise  as  to  fair  and  open  competition  in 
DoD  procurement.  In  addition,  future  availability  and  support 
questions  are  relevant. 

The  DoD  to  GOSIP  transition  may  include  an  extended  period 
of  coexistence.  In  order  for  internetworking  to  occur,  it  may 
be  necessary  to  provide  OSI  hosts  with  the  ability  to 
communicate  with  other  OSI  hosts  on  a  DoD-based  network. 
Multiple  protocol  stack  gateways  and  routers  provide  a 
transitional  path  between  legacy  systems  and  a  complete  OSI 
environment.  Current  capabilities  are  maintained  through  the 
implementation  of  Application  Layer  Gateways  and  the  ISO 
Development  Environment  (ISODE). 
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The  TCP/IP  Internet  and  the  OSI/CLNP  Internet  communities 
are  moving  together  to  develop  standards  recommendations  that 
all  sides  can  agree  on.  By  creating  an  "anything  over 
anything"  environment,  applications  will  run  over  APIs  and 
multiple  application  services  implementations  for  effective 
interoperability.  Through  application  gateways,  application 
services  will  run  over  multiple  transport  service  protocol 
stacks  identified  by  internetwork  addresses  and  define  a  new 
type  of  standard  that  incorporates  the  best  functions  from 
both  legacy  and  proposed  environments  [GOSIP  Institute,  1993]. 

B.  CONCLUSIONS 

Commercial  off  the  shelf  application  software  vendors, 
hardware  manufacturers,  and  operating  systems  vendors  race 
headlong  towards  global  interconnectivity,  in  a  truly  "open 
system"  while  the  Government  and  standards  bodies  (justifying 
their  own  existence)  promote  some  aberration  of  "openness". 
Open  systems  hardware  and  software  (TCP/IP,  OSI  and  GOSIP)  are 
desirable  for  the  flexibility  they  offer,  but  are  acquired  by 
DoD  in  an  environment  of  ultimate  rigidity  and  inflexibility. 
GOSIP  migration,  as  directed  by  NIST,  is  achieving  compliance 
but  not  interoperability  and  complexity  rather  than 
flexibility.  A  major  "problem"  with  GOSIP  transition  is 
solvable  quite  simply,  sink  enough  money  into  transition  and 
products  will  flood  the  marketplace.  Questions  to  be 
addressed  are  whether  or  not  a  wholesale  replacement  of  the 
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infrastructure  is  the  most  cost  effective  way  to  move  into  the 
next  century,  and  is  transition  to  OSI  protocols  really  the 
problem.  I  believe  that  the  installed  base  is  too  entrenched, 
too  important  and  too  fragile  to  be  abandoned.  Legacy  systems 
must  evolve  into  the  next  generation  of  computing  not 
replaced.  The  second  question  speaks  to  the  mission  of  the 
Navy.  Our  mission  is  not  to  develop  the  worlds  perfect 
network,  it  is  to  use  the  computer  resources  necessary  to 
defend  the  Nation.  The  efficient  and  effective  accomplishment 
of  this  task,  with  respect  to  computers,  can  not  be  defined 
simply  by  a  standard  set  of  protocols.  When  OSI  protocols  are 
the  best  choice  to  solve  a  problem  (communication  with  NATO) 
or  accomplish  a  task,  then  they  should  be  used.  If  the 
situation  requires  a  different  set  of  protocols  (TCP/IP,  SNA, 
Mac)  then  that  should  be  used,  interconnection  can  be  used  as 
an  option  if  interoperability  is  necessitated. 

This  thesis  addresses  the  mechanics  of  GOSIP  and 
requirements  of  FIPS  146-1.  My  conclusion  points  away  from 
transition.  I  believe  that  the  requirements  of  GOSIP  have 
missed  the  mark.  Global  interconnectivity  should  be  a  goal  in 
developing  technology,  but  Naval  Officers  are  problem  solvers 
who  use  technology  as  tools  and  our  problem  is  not  transition. 
The  problems  we  face  are  dynamic  and  can  not  be  captured  in  a 
single  set  of  protocols.  The  simple  truth  is  that  every 
computer  in  the  DoD  does  not  need  to  interconnect  and 
interoperate  with  every  other  computer  in  the  world.  In 
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today's  environment  of  fiscal  restraint  we  can  afford  to  get 
the  job  done  but  nothing  more. 

The  goals  of  GOSIP  are,  however,  important  and  have  merit, 
but  the  solution  is  not  found  in  FIPS  146-1.  The  computer 
industry  is  creating  an  environment  where  interoperability 
will  be  built  into  systems  as  a  matter  of  course.  In  the  last 
five  years  commercial  software  has  gone  from  proprietary  stand 
alone  programs  to  almost  complete  openness.  The  computing 
engines  and  kernels  of  programs  are  shared  between  vendors 
allowing  transparent  conversion  (Lotus,  Excel,  Word,  Word 
Perfect).  Off  the  shelf  "Gator  boxes"  are  connecting 
heterogenous  networks  for  pennies.  Hardware  developments  such 
as  the  PowerPC  601  processor  from  IBM,  Apple  and  Motorola  will 
bridge  the  gap  between  RISC,  Mac  and  DOS.  Before  this  thesis 
is  printed  the  concepts  of  networking  and  distributed 
computing  will  be  significantly  altered  by  this  processor 
alone.  Technology  is  advancing  at  rapidly  increasing  speed 
towards  complete  interoperability  and  standards  while  dictate 
procurement  can  not  hope  to  keep  pace.  The  marketplace  is 
offering  global  interconnectivity  with  cost  effective 
solutions.  The  government  can  not  afford  to  be  a  unique 
outlet  for  OSI  and  support  an  entire  industry.  Neither  can 
DoD  afford  to  abandon  legacy  systems. 
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C.  SOLUTIOMS 


A  major  problem  facing  government  IS  managers  is  how  to 

improve  and  expand  computer  resources  to  support  a  command's 

mission  within  the  constraints  of  budgets  and  the  GOSIP 

requirements.  At  issue  is  whether  or  not  GOSIP  systems  will 

efficiently  and  cost  effectively  deliver  the  support  needed. 

The  lament  of  the  computer  professional  has  become: 

"Do  you  want  GOSIP  compliance,  or  do  you  want  it  to  work?" 
[Breidenbach,  1992] 

Unfortunately  for  those  in  DoD,  the  answer  is  "yes".  For  the 
IS  manager  constrained  by  GOSIP  procurement  regulations  there 
are  four  basic  approaches  to  transition  [Becker,  1992]: 

•  Do  nothing  and  wait  for  a  full  set  of  standards  to  emerge; 

•  Have  custom  interfaces  developed; 

•  Gradually  implement  the  available  OSI  or  other  standards- 
based  products  as  they  come  to  the  market;  or 

•  Purchase  coexistence  products  that  enable  dissimilar 
systems  to  talk  whether  or  not  these  products  are 
standards-based . 

The  answer  supported  by  this  thesis  is  the  latter,  however 

each  organization  must  asses  it's  own  needs  and  find  products 

that  support  the  individual  mission.  Industry  leaders  in  the 

standards  process  are  moving  in  a  new  direction  that  will 

facilitate  open  systems  and  reduce  conflict. 

The  focus  is  being  taken  off  of  OSI.  The  issue  is  not  "Is 
OSI  good,  and  will  it  win  out?"  but  rather  "How  can  [we] 
provide  the  technical  means  to  manufacture  products  that 
users  want  to  buy  to  achieve  interoperable,  manageadile 
open  communications  systems?"  [Becker,  1993] 
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Computer  companies,  networking  companies  and  standards 
organizations  eschew  open  systems  orthodoxy  but  users  don't 
buy  protocols,  they  buy  applications.  Multiprotocol 
networking,  protocol  coexistence  to  support  migration  is  the 
only  responsible  course  of  action,  and  the  only  one  users  will 
support  [Metcalfe,  1993]. 

D.  AREAS  REOmMElfDEO  FOR  FURTHER  RESEARCH 

1.  Industry  and  Government  Open  Systems  Specification 

Industry  and  Government  Open  Systems  Specification 
(IGOSS)  is  being  developed  as  a  follow-on  protocol 
specification  to  GOSIP.  A  number  of  manufacturing  companies 
and  federal  agencies  are  working  to  develop  the  standard  to 
improve  GOSIP  by  adding  Remote  Database  Access,  improvements 
to  X.400  and  transaction  processing.  IGOSS  covers  a  wider 
range  of  functionality  than  GOSIP  and  it  is  expected  to  expand 
the  standard  by  adding  seventeen  new  function  areas  [NIST, 
1993] . 

2 .  INTERNET  2000 

The  GOSIP  Institute  and  the  Networking  Institute  are 
private  educational  organizations  devoted  to  explaining  and 
demonstrating  open  systems  networking,  applications,  software, 
and  data  technologies.  The  proposed  INTERNET  2000  is  quickly 
becoming  a  driving  force  in  shaping  the  future  of  open 
systems.  If  the  efforts  of  the  GOSIP  Institute  are  successful 
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there  may  be  a  wholesale  reevaluation  of  current  standards  in 
an  attempt  to  create  a  single  convergence  standard. 

3.  SAFEMET 

The  SurviveUsle  Adaptable  Fiber  Optic  Embedded  Network 
(SAFENET)  is  the  application  of  open  systems  in  Navy  Mission 
Critical  Systems.  The  adoption  of  an  industry  network 
standard  is  intended  to  provide  innovative  technology,  better 
service  and  improved  products  for  the  Navy.  The  objective  of 
the  SAFENET  standard  program  is  to  develop  computer  network 
standards  that  support  the  needs  of  shipboard  mission-critical 
computer  resources.  These  needs  include  increased 

connectivity,  survivcdiility ,  performance,  and  capacity  for 
future  system  growth.  The  SAFENET  standard,  originally  based 
solely  on  GOSIP,  is  evolving  to  including  non-OSI  protocols 
and  legacy  capabilities. 


79 


APPBMT'IX  A.  GOSIP  PRIMCIPLES 


A.  DONAIH  ORGAHIXATION 

The  topology  of  an  internetwork  has  a  significant  effect 
in  administering  the  network,  allocating  addresses,  and 
network  management.  This  section  discusses  the  basic  ISO 
model  of  internetwork  domains.  Figure  A-1  shows  the  ISO 
routing  architecture  used  during  this  discussion. 


Figure  A-1  ISO  Routing  Model 
1.  Routing  Domains  (ROs) 

A  routing  domain  is  a  group  of  routers  using  a  common 


routing  information  distribution  protocol,  common  metrics  to 
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express  cost,  speed,  delay,  or  other  link  attributes,  and  a 
common  method  of  computing  a  path  using  performance  based 
calculations  (ISO  Technical  Report  (TR)  9575). 

2.  Administrative  Doaiain  (AD) 

Collecting  one  or  more  routing  domains  may  constitute 
an  AD.  ADs  control  the  organization  of  RDs,  the  assignment  of 
addresses,  and  other  policies.  Different  protocols  may  be 
used  between  routers  in  separate  ADs. 

3 .  Routing  Protocols 

It  is  widely  accepted  within  the  internetworking 
industry  that  the  most  dynamic  and  robust  solutions  lie  within 
distributed  adaptive  routing  where  end-systems  (ESs)  and 
intermediate  systems  (ISs)  learn  from  one  another's  location 
and  attributes  by  communication  directly.  Figure  A-2  shows 
these  protocols  defined  by  ISO,  scheduled  for  usage  in  GOSIP. 

a.  ES-IS  Protocol  (ISO  9542) 

This  routing  standard  is  used  for  mutual  discovery 
by  ESs  and  ISs.  It  supports  broadcasting  on  LAN  subnetworks, 
and  allows  an  IS  to  redirect  an  ES  toward  another  IS.  Finally, 
it  allows  ISs  to  exchange  static  routing  information  with 
other  ISs  when  they  do  not  wish  to  use  the  more  dynamic  ISO 
protocols. 

b.  IS-IS  Protocol  (ISO  10589) 

This  standard  is  used  to  exchange  reachability 
information  with  other  ISs.  It  is  designed  to  operate  within 
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Figure  A-2  ISO  Routing  Protocols 

a  routing  domain. 

c.  Inter-Domain  Routing  Protocol  (IDRP) 

This  standard  is  used  to  exchange  dynamic  routing 
information  across  routing  domain  boundaries.  IDRP  also 
supports  exchange  of  path  information,  which  could  be  used  for 
policy-based  routing  decisions.  Such  decisions  could  be  used 
to  select  low  cost  routes,  to  restrict  domains  used,  or  to 
enforce  other  policies. 

4.  Distributed  Backbone  Topology 

This  topology  contains  a  small  nximber  of  transit 
routing  domains  and  a  larger  number  of  site  routing  domains. 
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Figure  A-3  provides  a  diagreun  of  this  topology.  These  are  the 
characteristics  of  this  topology: 

•  Interconnections  between  site  RDs  are  made  through 
backbone  routers  in  the  Transit  Routing  Domains  (TRDs). 

•  Arbitrary  levels  of  hierarchy  may  be  introduced  within  the 
site  domains. 

•  All  local  traffic  is  handled  in  the  site  RDs. 

•  ESs  and  routers  would  derive  their  addressing  authority 
from  the  local  RD  within  their  site  RD. 

•  TRDs  are  centrally  administered  by  groups  responsible  for 
coordinating  all  aspects  of  interconnection. 

•  Site  routers  comply  with  an  interface  specification 
governing  routing  protocols/  network  management,  security 
and  other  operational  aspects. 


Figure  A-3  Distributed  Routing  Backbone  Topology 
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5.  Routing  Oonain  Size 


Large  routing  domains  degrade  router  performance  due 
to  the  size  of  link  states  being  maintained  for  IS-IS 
communications.  Small-to-medium  RDs  should  be  administered 
from  aggregated  facilities  for  the  network. 

6.  OSI  CoBBnunication  Principles 

In  transferring  information,  certain  actions  are 
expected  before,  and  after,  the  message  passes  a  specific  OSI 
layer.  Each  information  transfer  function  is  uniquely 
identified  through  the  transfer  of  service  primitives 
(protocol  parameters)  at  OSI  layer  access  points.  In  Figure 
A-4,  an  arbitrary  protocol  layer  is  identified  as  the  nth 
layer.  The  layer  above  is  identified  as  the  (n  +  1),  and  the 
protocol  layer  below  is  identified  as  the  (n  -  1)  layer.  The 
(n  -  1)  protocol  layer  is  the  service  provider  and  the  (n  +  1) 
protocol  layer  is  the  service  user  as  shown  in  Figure  A-4. 
These  OSI  layer  access  points  are  identified  within  the 
protocol  header  using  a  particular  layer's  access  point 
selector.  This  allows  developers  to  write  Application  Program 
Interfaces  (APIs)  which  efficiently  interface  the  application 
program  in  a  standard  way  to  an  operating  system.  This  allows 
for  more  efficient  portability  of  software. 

As  a  GOSIP  transition  tool,  this  is  an  effective  point 
to  place  a  "translator"  or  gateway  to  non-GOSIP  software  or 
protocols.  Existing  application  software  which  does  not 
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comply  with  OSI  protocol  standards  passes  information  to  the 
API  which  translates  the  information  to  a  form  which  conforms 
to  OSI  protocol  specifications. 


Figure  A-4  OSI  Communications  Principles 
a.  Service  Access  Points 

The  protocol  layers  communicate  required  services 


between  layers  through  Service  Access  Points  (SAPs).  These 
access  points  are  identified  as  the  Presentation  Service 
Access  Point  (PSAP),  Session  Service  Access  Point  (SSAP), 
Transport  Service  Access  Point  (TSAP),  and  Network  Service 
Access  Point  (NSAP).  Figure  A-5  shows  this  model  of  OSI  layer 
service  access  points.  The  NSEL  field  of  the  NSAP  address 
structure  determines  the  type  of  access  point. 
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b.  Network  Service  Access  Point  (NSAP) 

The  Network  layer  provides  for  end-to-end 
transmission.  This  means  that  higher  layers  need  not  be 
concerned  with  the  physical  topology  of  the  network.  This 
independence  from  concerns  of  the  network  topology  is 
accomplished  by  providing  logical  network  address  mechanisms 
to  higher  layers.  This  logical  address  is  called  NSAP.  The 
NSAP  address  is  used  to  identify  a  user  of  the  network  service 
on  a  remote  system,  as  opposed  to  the  remote  system  network 
layer  itself.  This  identifier  uniquely  distinguishes  one  ES 
from  another  in  a  network  of  systems. 

A  directory  mapping  function  may  be  required  to 
relate  a  NSAP  address  to  its  associated  Sub-Network  Point  of 
Attachment  (SNPA)  address  to  permit  the  network  service 
provider  to  determine  the  routing.  The  SNPA  is  the  address 
that  identifies  a  real  open  system  on  a  particular  rubnetwork 
and  is  in  the  format  of  whatever  addressing  scheme  is  used  on 
the  particular  subnetwork.  An  example  of  a  SNPA  address  are 
the  physical  layer  addresses  of  IEEE  802  style  LANs.  Figure 
A-6  shows  routing  domains  and  an  ES's  SNPA  is  shown  in  the 
figure.  An  NSAP  address  does  not,  in  theory,  have  to  include 
any  information  relevant  to  subnetwork  routing  but  it  is 
recognized  that,  in  practice,  NSAP  addresses  (in  particular 
the  Domain  Service  Part  (DSP) )  should  be  constructed  in  such 
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a  way  that  routing  through  interconnected  subnetworks  is 
facilitated. 


ISO  8348  describes  NSAP  addresses.  The  principle 
idea  behind  NSAP  addresses  is  that  they  are  assumed  to  be 
essentially  stable,  globally  unique  identifiers  of  NSAPs.  The 
global  identification  of  NSAPs  does  not  imply  the  universal 
availability  of  the  directory  functions  required  to  enable 
communication  cunong  all  NSAPs  to  which  NSAP  addresses  have 
been  assigned. 


BR  •  Boundary  Router 

ES  •  End  System 

IS  -  Intennodlate  System 

R  -  Router 

SNPA  -  Subnetwork  Point  of  Attechment 


Figure  A-6  OSI  Routing  Topology 


(1 )  NSAP  Structure 

NSAP  addresses  have  a  structure  that  is 


composed  of  two  main  parts:  Initial  Domain  Part  (IDP)  and 


Domain  Specific  Part  (DSP).  The  DoN  will  use  the  GOSIP  2.0 
NSAP  address  format.  Figure  18  provides  the  generic  NSAP 
address  structure  from  GOSIP  Version  2.0  to  be  used  for  NSAP 
address  registration. 

(2)  Initial  Domain  Part 

The  IDP  associates  a  particular  registration 
authority  for  that  class  of  NSAP  addresses,  as  well  as  the 
format  for  the  rest  of  the  NSAP  address.  The  IDP  is 
subdivided  into  two  parts:  the  Authority  Format  Identifier 
(AFI)  and  Initial  Domain  Identifier  (IDI). 

(3)  Authority  Format  Identifier 

The  first  part,  AFI,  identifies  the  format 
being  used  for  the  IDI,  identifies  the  authority  responsible 
for  assigning  the  NSAP  address  values  and  gives  the  abstract 
syntax  of  the  DSP.  GOSIP  uses  an  AFI  value  of  47. 

(4 )  Initial  Domain  Identifier 

The  second  part,  IDI,  specifies  the  domain  to 
which  the  address  belongs.  The  IDI  value  0005  represents  the 
routing  domain  which  has  been  assigned  to  the  U.S.  Government 
(non-tactical ) .  The  IDI  value  of  0006  has  been  reserved  for 
tactical  use  by  DoD. 

(5)  Domain  Specific  Part 

The  format  for  the  DSP  is  not  defined  by  the 
standard  but  must  be  estcdslished  by  the  Reservation  Authority 
for  the  0005  domain.  The  standard  allows  a  maximum  length  of 
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20  octets  for  the  NSAP  and  this  has  been  allocated  as  shown  in 
figure  A-7.  The  AFI  of  47  occupies  one  octet,  and  the  IDI  of 
0005  occupies  two  octets.  These  two  values  are  encoded  as 
decimal  digits.  The  DSP  is  allocated  into  the  following 
parts:  DSP  Format  Identifier  (DFI)  one  octet,  Administrative 
Authority  (AA)  identifier  three  octets.  Routing  Domain  (RD) 
two  octets.  Area  two  octets,  ES  identifier  six  octets  and  NSAP 
Selector  (NSEL)  one  octet.  Reserved  (RSVD)  has  two  octets  for 
expansion. 

(6)  DSP  Format  Identifier 

The  DFI  identifies  the  version  of  the  DSP 
structure  and  associated  semantics  encoded  within  an  NSAP 
address.  GOSIP  Version  2.0  has  assigned  the  DPI  value  80H  to 
the  NSAP  structure. 

(7)  Administrative  Authority 

The  AA  identifier  specifies  the  central 
authority  within  a  GOSIP  Administrative  Domain  for  addressing. 

(8)  Routing  Domain 

A  RD  is  a  set  of  ESs  and  ISs  which  operate 
according  to  the  same  routing  procedures  is  controlled  by  a 
single  administrative  authority  and  which  is  wholly  contained 
within  a  single  administrative  domain.  An  administrative 
domain  could  be  all  the  network  entities  under  the  control  of 
a  government  agency.  Administrative  domains  can  have  multiple 
routing  domains.  The  administrative  domain  in  this  context  is 
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not  synonymous  with  the  Message  Handling  System  (MHS) 
Administrative  Management  Domain  (ADMD).  MHS 
Originator/Recipient  (0/R)  addresses  exist  in  a  separate 
hierarchy  from  NSAP  addresses.  The  SRA  will  maintain  a  list 
of  all  assigned  routing  domains  consistent  with  the 
established  naming  conventions  already  existing.  End  System 
naming  will  be  under  the  control  of  the  routing  domain 
authorities.  A  RD  identifier  corresponds  to  the  organization 
field  in  DoN  naming  conventions. 

(9 )  Area 

An  Area  field  uniquely  identifies  a  subdomain 
of  the  routing  domain.  An  Area  identifier  corresponds  to  the 
Group  field  in  Marine  Corps  naming  conventions. 

(10)  End  System  Identifier 

The  ES  identifier  field  identifies  a 
unique  system  within  an  area.  The  value  of  the  ES  identifier 
field  may  be  a  physical  address,  i.e.,  SNPA  address,  or  a 
logical  address.  A  locally  administered  table  is  used  to  map 
the  logical  address  to  a  corresponding  physical  address.  An 
ES  identifier  corresponds  to  the  User  field  in  marine  Corps 
naming  conventions. 

(11)  NSAP  Selector 

The  NSEL  field  allows  the  system  to  find 
the  appropriate  user  of  the  network  layer  service  within  that 
ES.  This  is  done  by  examining  the  value  of  the  NSEL.  The 
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first  bit  of  the  NSEL  field  identifies  whether  the  network 
service  is  connectionless  ( 0 )  or  connection-oriented  ( 1 ) . 
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Figure  A-7  OS I  Network  Service  Access  Point  Structure 


B.  GOSIP  ADDRESS  REGISTRATION  PROCEDURE 

GOSIP  addresses  are  registered  into  the  GOSIP  Directory 
using  ISO  3166,  Codes  for  the  Representation  of  Names  of 
Countries.  The  United  States  has  been  assigned  a  code  of  US 
and  USA  with  a  numerical  code  of  840.  Under  US,  the  American 
National  Standards  Institute  (ANSI)  has  assigned  the  Federal 
Government  the  code  of  GOV  with  a  numerical  code  of  101. 
General  Services  Administration  (GSA)  has  been  delegated  the 
authority  for  assigning  codes  under  code  101.  The  objects 
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used  for  inter-computer  communications  must  be  registered  with 
the  DoD  registration  authority  to  assure  interoperability 
among  the  network  users.  This  assurance  is  gained  from 
unique,  uneimbiguous  identifiers.  Objects  included  in  the 
protocol  standard  need  no  be  registered  by  users. 
Registration  only  becomes  necessary  when  objects  are  not 
included  in  protocol  standard  specifications. 

Objects  are  registered  in  a  hierarchical  structure  as 
shown  in  figure  A-8.  ISO  6523,  Structure  for  the 
Identification  of  Organizations,  is  used  to  identify 
organizational  names.  The  national  Institute  of  Standards  and 
Technology  has  been  assigned  as  the  network  Registration 
Authority  for  the  United  States.  The  GSA  has  been  named  the 
Executive  Agent  for  Government  Agencies.  The  DoD  Executive 
Agent  is  assigned  to  DISA.  The  Navy  Sub-Registration 
Authority  (SRA)  is  NCTS,  Washington,  D.C.  and  the  Marine  Corps 
SRA  for  registering  user  information  for  OSI  objects  with  the 
Don  RA  is  vested  in  Director  MCCTA,  Quantico  for  tactical  and 
tactical  support  users.  GOSIP  registration  falls  within  three 
broad  categories:  NSAP,  Names  (Message  Handling  System 
(X.400),  directory  (X.500))  and  Application-specific  (FTAM, 
VT,  Private  Message  Body  Parts,  Document  Application  Profiles, 
i.e..  Object  Identifiers  (OID)). 

1.  Names  Registration 


93 


ISO/CCITT 

1 

NSAP 

1 

I 

X.400 

1 

X.500 

— 1 

OID 

I 

CCITT 

1 

ISO 

1 

JOINT 

1  I 

CCITT  ISO 

1 

JOINT 

1 - 1 - 1 

CCITT  ISO  JOINT 

1 

1  1  1 
CCITT  ISO  JOINT 

1 

ICD 

1, 

1  1  1 

0  12 

1 

“1 

3 

1  in  1 

0  12  3 

C 

1  ^  1 
12  3 

1 

0004 

1 

0005 

1 

0006 

^  1 

0014  ANSI 

1 

US 

OSINET 

GOVT 

1 

DoO 

(840) 

1  I 

STATES/ 

1  1 

ORG  STDS 

1 

AA 

1 

GOVT 

1 

ANSI 

GOV 

(101) 

RD 

1 

PRMD 

1 

1 

1  1 
STATES/  ORG 

n 

STDS 

AREA 

ORG 

GOVT 

1 

ES 

1 

GROUP 

1 

DISTINGUISHED 

NAMES 

0 

Inteinacional 

Standards 

(DN) 

1 

!l 

Registiaticn 

Authority 

ORG 

2 

Member  Body 

GROUP 

h 

Identified  | 

Organization 

1 — 

Figure  A-8  GOSIP  Address  Registration  Tree 


Originator/recipient  (0/R)  names  are  assigned  by  a 
Registration  Authority  for  use  in  X.400  MHSs.  These  names 
consist  of  alphabetic  and  numeric  characters.  0/R  names  are 
organizationally  structured,  analogous  to  Plain  Language 
Address  Designators  (PLADs).  An  assigned  name  may  have  the 
following  attributes; 

•  PrivateDomainNcune  (16  characters  meoc) 

•  OrganizationNeune  (64  characters  max) 

•  OrganizationalUnit  (32  characters  max) 

2.  Application-specific  Registration 

This  group  of  objects  requires  specific  registration 
of  their  profile  as  this  situation  differs  from  address 
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registration.  The  format  of  each  profile  specifies  data  field 
construction  to  assure  interoperability.  These  objects 
include  File  Transfer,  Access  and  Management  (FTAM),  document 
type  names,  MHS  Private  Body  Parts,  Virtual  Terminal  (VT) 
Profiles  and  Control  Objects  and  Document  Application  Profiles 
(DAP).  Registration  of  FTAM  Document  Types,  MHS  Private  Body 
parts,  VT  Profiles  and  Control  Objects  and  Document 
Application  Profiles  is  optional  and  should  be  requested  only 
under  special  circumstances. 
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